New submission from Skip Montanaro <skip.montan...@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 >>> 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. ---------- assignee: docs@python components: Documentation, IO, Interpreter Core messages: 310237 nosy: docs@python, skip.montanaro priority: normal severity: normal status: open title: File object 'name' attribute inconsistent type and not obviously documented type: behavior versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32594> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
