[issue26158] File truncate() not defaulting to current position as documented

Change by Eryk Sun : -- type: -> behavior versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6 ___ Python tracker ___ __

[issue26158] File truncate() not defaulting to current position as documented

random832 added the comment: In the analogous C operations, ftell (analogous to .tell) actually causes the underlying file descriptor's position (analogous to the raw stream's position) to be reset to be at the same value that ftell has returned. Which means, yes, that you lose the benefits of

[issue26158] File truncate() not defaulting to current position as documented

Martin Panter added the comment: Fornax: Yes, I was suggesting the idea of deprecating truncate() for text files! Although a blanket deprecation of all cases may not be realistic. Quickly reading the Stack Overflow pages, it seems like there is demand for this to work in some cases. Deprecatin

[issue26158] File truncate() not defaulting to current position as documented

Eryk Sun added the comment: FYI, you can parse the cookie using struct or ctypes. For example: class Cookie(ctypes.Structure): _fields_ = (('start_pos', ctypes.c_longlong), ('dec_flags', ctypes.c_int), ('bytes_to_feed', ctypes.c_int),

[issue26158] File truncate() not defaulting to current position as documented

Марк Коренберг added the comment: text files and seek() offset: issue25849 -- nosy: +mmarkk ___ Python tracker ___ ___ Python-bugs-lis

[issue26158] File truncate() not defaulting to current position as documented

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue26158] File truncate() not defaulting to current position as documented

Fornax added the comment: I don't have a specific use case. This spawned from a tangentially-related StackOverflow question (http://stackoverflow.com/questions/34858088), where in the answers a behavior difference between Python 2 and 3 was noted. I couldn't find any documentation to explain i

[issue26158] File truncate() not defaulting to current position as documented

Martin Panter added the comment: In theory, TextIOWrapper could rewrite the last bit of the file (or the whole file) to have the requested number of characters. But I wonder if it is worth it; maybe deprecation is better. Do you have a use case for any of these bugs, or are you just playing ar

[issue26158] File truncate() not defaulting to current position as documented

Serhiy Storchaka added the comment: May be. Looking at the code, both Python and C implementations of TextIOWrapper look incorrect. Python implementation: def truncate(self, pos=None): self.flush() if pos is None: pos = self.tell() return self.buffer.tru

[issue26158] File truncate() not defaulting to current position as documented

Fornax added the comment: Another surprising result: >>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n') 32 >>> f = open('temp.txt', 'r+') >>> f.write('test') 4 >>> f.close() >>> open('temp.txt').read() 'testE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n' >>> open('temp.txt', 'w').wri

[issue26158] File truncate() not defaulting to current position as documented

Fornax added the comment: After taking a little time to let this sink in, I'm going to play Devil's Advocate just a little more. It sounds like you're basically saying that any read-write text-based modes (e.g. r+, w+) should be used at your own peril. While I understand your UTF-7 counterexa

[issue26158] File truncate() not defaulting to current position as documented

Fornax added the comment: Heh... building on Serhiy's example: >>> f.tell() 680564735109527527154978616360239628288 I'm way out of my depth here. The results seem surprising, but I lack the experience to be able to say what they "should" look like. So I guess if it's working as intended and j

[issue26158] File truncate() not defaulting to current position as documented

Serhiy Storchaka added the comment: This is not always possible. Consider following example: >>> open('temp.txt', 'wb').write(b'+BDAEMQQyBDMENA-') 16 >>> f = open('temp.txt', 'r+', encoding='utf-7') >>> f.read(2) 'аб' What should be the result of truncating? I think it would be better to not i

[issue26158] File truncate() not defaulting to current position as documented

Eryk Sun added the comment: Serhiy, why doesn't truncate do a seek(0, SEEK_CUR) to synchronize the buffer's file pointer before calling its truncate method? This also affects writing in "+" modes when the two file pointers are out of sync. -- nosy: +eryksun ___

[issue26158] File truncate() not defaulting to current position as documented

Fornax added the comment: To clarify... the intended behavior is for truncate to default to the current position of the buffer, rather than the current position as reported directly from the stream by tell? That seems... surprising. -- ___ Python t

[issue26158] File truncate() not defaulting to current position as documented

Serhiy Storchaka added the comment: This is because the file is buffered. >>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n') 32 >>> f = open('temp.txt', 'r+') >>> f.readline() 'ABCDE\n' >>> f.tell() 6 >>> f.buffer.tell() 32 >>> f.buffer.raw.tell() 32 The documentation nee

[issue26158] File truncate() not defaulting to current position as documented

Changes by Stephen Paul Chappell : -- nosy: +Zero ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue26158] File truncate() not defaulting to current position as documented

New submission from Fornax: io.IOBase.truncate() documentation says: "Resize the stream to the given size in bytes (or the current position if size is not specified). The current stream position isn’t changed. This resizing can extend or reduce the current file size. In case of extension, the c