[New-bugs-announce] [issue32594] File object 'name' attribute inconsistent type and not obviously documented
report at bugs.python.org
Thu Jan 18 08:51:34 EST 2018
New submission from Skip Montanaro <skip.montanaro at gmail.com>:
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
>>> f = open(sys.stderr.fileno())
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():
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.
assignee: docs at python
components: Documentation, IO, Interpreter Core
nosy: docs at python, skip.montanaro
title: File object 'name' attribute inconsistent type and not obviously documented
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce