[issue44013] tempfile.TemporaryFile: name of file descriptor cannot be reused in consecutive initialization
New submission from Xiang Zhong : The variable of instance cannot be reused in two consecutive codes chunk combinations. Please check the difference in attached file, xtempfile.py, function: test_3 & test_4. However, surprisingly, the problem can be fixed in test_5 and test_6. Which may be helpful for debug: why does the value of "id(fd.name)" keep constant all the time inside those combinations? -- components: Library (Lib) files: xtempfile.py messages: 392746 nosy: zhongxiang117 priority: normal severity: normal status: open title: tempfile.TemporaryFile: name of file descriptor cannot be reused in consecutive initialization type: behavior versions: Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50004/xtempfile.py ___ Python tracker <https://bugs.python.org/issue44013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44013] tempfile.TemporaryFile: name of file descriptor cannot be reused in consecutive initialization
Xiang Zhong 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 <https://bugs.python.org/issue44013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44013] tempfile.TemporaryFile: name of file descriptor cannot be reused in consecutive initialization
Xiang Zhong added the comment: Dear Mr. Jollans, Thanks for your additions, I think I know well about the SHELL programming language, now, every thing about the low-level file descriptors is linked together. I guess now I completely know your writing, thanks again for your detail explanations! The potential “bug” of your consideration is the post operation caused by OS.close() in the delay/conflict of tempfile.Temporary(), as a result, fd does not know whether its linked file descriptor is valid or not due to “with” method. However, if you have a look on “test_4” in attached “xtempfile.py”, you will see that in the first fd generated by tempfile.Temporary(), it is assumed to be handled by the first “with”, no more other operations are executed. Even after first “with” it becomes invalid, there are no further executions performed. On the second fd returned by tempfile.TemporaryFile(), it should be a valid file descriptor no matter how the first one is dealt with. From the coding perspective, these two variables are just “happen to” be the same chars. Besides, from my testing, changing any one of them to the different variable name, then the problem is gone. Furthermore, if you have a look on “test_3”, “test_5” and “test_6” (xtempfile.py), especially on “test_5”, they all prove that it should be a bug. To go deeper, I attached another test file “new-xtempfile.py”, on “test_11”, you will see that it should have some problems on "__del__" method if its linking file descriptor is closed by os.close(). They two may or may not be the same problem. Thanks again for your illustration of “fd.fileno()” and “fd.name”. -- ___ Python tracker <https://bugs.python.org/issue44013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44601] argparse: potential bugs on add_subparser due to allow_abbrev cannot deal with short options
New submission from Xiang Zhong : Additional argument like "allow_abbrev_short" should be added to avoid those potential bugs due to abbreviations on short options cannot be handled by "allow_abbrev". To reproduce and be well explanation, please check on my attached testing file. The following is the excerpt: 1) contents in link: https://docs.python.org/3/library/argparse.html#prefix-matching should be updated to long options (two dashes) 2) bugs may happen due to `allow_abbrev' cannot handle short options when recycling top-level arguments by using `add_subparsers' -- components: Library (Lib) files: myargparse.py messages: 397268 nosy: zhongxiang117 priority: normal severity: normal status: open title: argparse: potential bugs on add_subparser due to allow_abbrev cannot deal with short options type: behavior versions: Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50143/myargparse.py ___ Python tracker <https://bugs.python.org/issue44601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
