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.

Author skip.montanaro
Recipients docs@python, skip.montanaro
Date 2018-01-18.13:51:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
In-reply-to
Content
I stumbled on what I think is an inconsistency in the "name" attribute of file objects. When a file is opened with an existing file descriptor, the "name" attribute is of type int (this from a 3.6.4 session, but it also exists in 2.7):

>>> import sys
>>> sys.stderr.name
'<stderr>'
>>> f = open(sys.stderr.fileno())
>>> f.name
2
>>> type(f.name)
<class 'int'>

I thought it odd that the standard I/O objects would be blessed with string filenames (despite not representing real filesystem paths), but that files opened by file descriptor would have that file descriptor as their name.

I looked in the documentation for open():

https://docs.python.org/3/library/functions.html#open

but saw no mention of the "name" attribute at all. In fact, the first argument to open() is called "file", so it's not obvious that the "name" attribute needs to be a copy of that parameter.

It seems to me that "name" attributes of open file objects should be of a consistent type, even if they might not represent an actual path in the filesystem. Even if this dual-type behavior is retained, it should be documented.
History
Date User Action Args
2018-01-18 13:51:34skip.montanarosetrecipients: + skip.montanaro, docs@python
2018-01-18 13:51:34skip.montanarosetmessageid: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>
2018-01-18 13:51:34skip.montanarolinkissue32594 messages
2018-01-18 13:51:34skip.montanarocreate