Martin Panter added the comment: I agree that the business with “name” is a mess. I don’t know what the best solution is. FileIO.name is already documented as being a file descriptor in some cases.
Perhaps we should document that the Buffered and Text wrappers inherit the wrapped name, but if the underlying object has no “name” attribute then neither does the wrapper object. E.g.: TextIOWrapper(BufferedReader(BytesIO())).name. Also document that a string name is more a rough description and may not be technically accurate, e.g. sys.stdin.buffer.raw.name is always "<stdin>". I’m not sure that changing the name to None would be much of an improvement over having it an integer file descriptor. It would probably hurt debugging and error messages. IMO it is the APIs like tarfile that are broken when they assume “name” is a technically valid file name string. In the tarfile module, there are two uses a file’s “name” attribute that I know of: TarFile constructor: Since the main change for Issue 21044 was made, the TarFile constructor only uses the underlying name attribute if it is str or bytes. TarFile.gettarinfo(): See Issue 21996 and my. I proposed some documentation in Issue 22468 to clarify the behaviour. In one use case, I had to override the “name” attribute with a dummy “arcname” argument, and then set the real name later on. ---------- nosy: +martin.panter _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26318> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
