Xiang Zhong <[email protected]> added the comment:
Dear Mr. Jollans, thanks for your comments and information.
I know my usage of tempfile.TemporaryFile() is unusual, technically I “open”ed
it twice. The reason I coded them in this way, as a simple illustration, is I
want to test/debug some codes of my early work which directly takes
“real-file-names” as the input.
Good to know “fd.fileno()” is more advance than “fd.name”, thank you for your
information.
For your writing, if my understanding is correct, you mean that os.close() and
tempfile.TemporaryFile() are using the same low-level file descriptor
sequences, which means they only keep track of their own file descriptor, and
assign new file descriptor to the “just” next one.
For example, assume file descriptor integer numbers: 1,2,3,4… as the low-level
sequences.
Firstly, call tempfile.TemporaryFile() will return 1 as the file descriptor.
Secondly, execute “with open..” will use 2 as the new one and finally it will
be closed.
Third, call tempfile.TemporaryFile() again, problem in here is, it will
sequentially take 2 (rather than 3) as the new file descriptor, because it only
keeps its own orders.
Since the file descriptor 2 is already used and closed inside second step in
with operation, so the OSError will happen, causing the file descriptor 2
cannot be reused.
Is my understanding correct?
However, I do not agree with that. To boil down my example codes,
fd = tempfile.TemporaryFile()
with open(fd.fileno()) as f:
pass # I know fd is closed after with is done
fd = tempfile.TemporaryFile() # since tempfile.TemporaryFile() is
# called again, it should return a
# valid file descriptor, and the above
# operations in “with” chunk should
# not influence its result
fd.seek(0) # this should work, however, in reality, it does not
Thanks for your example codes, but they are different with my examples. I even
found a new problem with it, please check my additional testing file:
“new-xtempfile.py” (which is attached).
I think those testings can be somehow explained your writing, however, it
should be a bug.
Finally, I would like to make some revisions,
TL;DR:
- having two file objects for the same file descriptor is asking for trouble
- __del__ method should not close its “just” next file descriptor, if its
current input is closed.
- I'd say they are "bug"(s)
----------
resolution: -> wont fix
Added file: https://bugs.python.org/file50093/new-xtempfile.py
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue44013>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
