This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: TemporaryFile name returns an integer in python3
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, jtaylor, ncoghlan, pitrou, r.david.murray, serhiy.storchaka, terry.reedy
Priority: normal Keywords:

Created on 2013-05-03 16:54 by jtaylor, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg188305 - (view) Author: Julian Taylor (jtaylor) Date: 2013-05-03 16:54
sys.version_info(major=3, minor=3, micro=1, releaselevel='final', serial=0)
In [3]: type(tempfile.TemporaryFile().name)
Out[3]: builtins.int

in python2 it returned a string, this is a somewhat pointless api change which breaks some third party code, e.g. numpy (https://github.com/numpy/numpy/issues/3302)
msg188311 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-05-03 17:30
The 'name' attribute of TemporaryFile is not part of the API.  It happens to exist only because the underlying file object has a 'name' attribute.  On posix platforms the value is not really useful for anything.  In other words, that numpy code was buggy to start with, the bug was just hidden by the fact that in python2 name happened to be a string ('<fdopen>'), and nobody looked at the result.  What numpy was doing with it produced a nonsense value, but I guess nobody noticed.

Now, that said, I don't know why the value changed between Python2 and Python3, and that might conceivably be a bug of some sort.  I'm guessing it is a consequence of the IO system rewrite and is not a bug per-se, but it might also be that there are improvements that could be made here.
msg188314 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-05-03 17:40
Given the following property of TemporaryFile:

"Under Unix, the directory entry for the file is removed immediately after the file is created. Other platforms do not support this; your code should not rely on a temporary file created using this function having or not having a visible name in the file system."
(from http://docs.python.org/dev/library/tempfile.html#tempfile.TemporaryFile)

I find it absurd to expect the name attribute to return an actual filename, since it won't exist anymore by the time you use it (under Unix, at least). So, we could return an invalid filename, but I don't see the point, and the current behaviour is as good as any other.

If you want a usable name, by definition you must use NamedTemporaryFile. Recommend closing.
msg188316 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-05-03 17:57
http://docs.python.org/3/library/io.html#io.FileIO.name

    The file name. This is the file descriptor of the file when no name is given in the constructor.
msg188865 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-05-10 19:01
Given that the changed behavior is documented and pretty obviously intentional, it is not a bug. The proposal would have to be that we 'enhance' 3.4 *or later* by reverting back to the 2.x -- and possibly break 3.0 to 3.3 code. We are not going to do that without extremely good reason.

For a nameless file, using the integer fd as a 'name' seems more truthful than '<fdopen>'. I believe the latter can be a actual filename on *nix. On Windows, while Explorer rejects it, there may be ways to bypass the check. The integer fd is also more useful than None and 'isintance(x.name, int)' is as easy to check as 'x.name is None'.
History
Date User Action Args
2022-04-11 14:57:45adminsetgithub: 62095
2013-05-10 19:01:23terry.reedysetstatus: open -> closed

nosy: + terry.reedy
messages: + msg188865

type: behavior -> enhancement
2013-05-03 17:57:11serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg188316
2013-05-03 17:40:31pitrousetnosy: + georg.brandl, ncoghlan
resolution: rejected
messages: + msg188314
2013-05-03 17:30:45r.david.murraysetnosy: + r.david.murray, pitrou
messages: + msg188311
2013-05-03 16:54:17jtaylorcreate