Why truncate when we open a file in 'w' mode in python

Question

I am going through Zed Shaw\'s Python Book. I am currently working on the opening and reading files chapters. I am wondering why we need to do a truncate, when we are alread

Answer 1

If you would READ the questions before asking it, he answers it for you:

Extra Credit: " If you feel you do not understand this, go back through and use the comment trick to get it squared away in your mind. One simple English comment above each line will help you understand, or at least let you know what you need to research more.

Write a script similar to the last exercise that uses read and argv to read the file you just created.

There's too much repetition in this file. Use strings, formats, and escapes to print out line1, line2, and line3 with just one target.write() command instead of 6.

Find out why we had to pass a 'w' as an extra parameter to open. Hint: open tries to be safe by making you explicitly say you want to write a file.

If you open the file with 'w' mode, then do you really need the target.truncate()?

Go read the docs for Python's open function and see if that's true." - Zed Shaw.

He explicitly wants you to find these things out for yourself, this is why his extra credit is important.

He also EXPLICITLY states that he wants you to PAY ATTENTION TO DETAIL. Every little thing matters.

Answer 2

That's just a reflection of the standard posix semantics. see man fopen(3). Python just wraps that.

Answer 3

While it's not useful to truncate when opening in 'w' mode, it is useful in 'r+'. Though that's not the OP's question, I'm going to leave this here for anyone who gets lead here by Google as I did.

Let's say you open (with mode 'r+', remember there is no 'rw' mode) a 5 line indented json file and modify the json.load-ed object to be only 3 lines. If you target.seek(0) before writing the data back to the file, you will end up with 2 lines of trailing garbage. If you target.truncate() it you will not.

I know this seems obvious, but I'm here because I am fixing a bug that occurred after an object that stayed the exact same size for years... shrank because of a signing algorithm change. (What is not obvious is the unit tests I had to add to prevent this in the future. I wrote my longest docstring ever explaining why I'm testing signing with 2 ridiculously contrived algorithms.)

Hope this helps someone.

Answer 4

Scenario:
I was making a ransomware and needed to encrypt the file, My aim is not to encrypt the complete file but that much only to corrupt it because I want it to be fast in what it does and so saving time in encrypting it all, so I decided to edit some text only.
Now If I use write then my purpose is destroyed here because I would have to write the file a to z. Then what can I do?
well here truncate can be put in use.

Below is my code which just takes a token of last 16 digits in a file:

with open('saver.txt', 'rb+') as f:
    text_len = len(f.read())
    f.truncate(text_len-16)
    f.close()

I open the file
Truncate only 16 characters from file which will be replaced by me later.
Notice I am using it in read only mode, If I use in write mode than File is truncated completely and it will throw error when our truncate command comes in.
Answering this question after 8.4 years. :)

Answer 5

It's redundant since, as you noticed, opening in write mode will overwrite the file. More information at Input and Output section of Python documentation.

Answer 6

So Zed Shaw calls truncate() on a file that is already truncated. OK, that's pretty pointless. Why does he do that? Who knows!? Ask him!

Maybe he does it to show that the method exists? Could be, but that would be pretty daft, since I've never needed to truncate a file in my 15 years as a programmer so it has no place in a newbie book.

Maybe he does it because he thinks he has to truncate the file, and he simply isn't aware that it's pointless?

Maybe he does it intentionally to confuse newbies? That would fit with his general modus operandi, which seems to be to intentionally piss people off for absolutely no reason.

Update: The reason he does this is now clear. In later editions he lists this question as a "common question" in the chapter, and tells you to go read the docs. It's hence there to:

1. Teach you to read the documentation.
2. Understand every part of code you copy paste from somewhere before you copy-paste it.

You can debate if this is good teaching style or not, I wouldn't know.

The number of "Help I don't understand Zed Shaws book"-questions on SO had dwindled, so I can't say that it's any worse than any other book out there, which probably means it's better than many. :-)