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.

Title: `, ...).name` returns numeric fd instead of None
Type: enhancement Stage: resolved
Components: IO, Library (Lib) Versions: Python 3.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: martin.panter, socketpair, terry.reedy, vstinner
Priority: normal Keywords:

Created on 2016-02-09 06:30 by socketpair, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (9)
msg259915 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-02-09 06:30
`, ...).name` returns numeric fd instead of None. This lead to some nasty bugs.

In order to bring consistency and make that predictable, please make `.name` for that case to return None. (and document it)
msg259928 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-02-09 11:55
In particular, `, ...)` can not be used with tarfile, since it use it's "name" property, and think that it is real file name, and not expecte it to be int.
msg259966 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-02-10 01:52
I agree that the business with “name” is a mess. I don’t know what the best solution is. 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. 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.
msg259978 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-02-10 05:28
in any case, passing INTEGER as name is wrong thing, since (due to duck typing), name should be a string.
msg260044 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-02-10 22:11
Hum, I don't think that it can be changed today. is an int since Python 2.6. Changing it may break applications for a little benefit.

> `, ...).name` returns numeric fd instead of None. This lead to some nasty bugs.

Why do you test None? Why not testing isinstance(name, int)?
msg260186 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-02-12 17:38
1. nasty bugs not in my code!
2. It is not documented that name may be an int, so if applications rely on undocumented stuff are definitely broken, so if IMHO we CAN change that.
3. It will be much stricter to delattr('name') instead of setting as None. This will automatically cure issue21996 and issue22208.
msg260187 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-02-12 17:40
oops, issue22208 is not related issue
msg260188 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-02-12 17:42
The main idea: if wile does not have a name, it should not have it!
msg260198 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-02-12 20:03
3.4 only gets security fixes.  3.5 only gets bug fixes.  Feature changes ('enhancements') are limited to future versions.

This is not a behavior issue because the code and doc match. says (as Martin paraphrased) 

    The file name. This is the file descriptor of the file when no name is given in the constructor."

As I remember, this was discussed when io was designed.  The alternatives to name = fd: no name attribute, name = '', name = None.  All are about equally easy to test, as long as the decision is documented, which is clearly is, contrary to the claim otherwise.  I believe the deciding factor is that fd has more information than nothing, even if redundant or useless.

In the absence of sufficient reason to break existing code that follows the doc, which we are generally loathe to do, the design change should be rejected.
Date User Action Args
2022-04-11 14:58:27adminsetgithub: 70506
2016-02-12 20:03:52terry.reedysetstatus: open -> closed

type: behavior -> enhancement
versions: - Python 3.4, Python 3.5
nosy: + terry.reedy

messages: + msg260198
resolution: rejected
stage: resolved
2016-02-12 17:42:47socketpairsetmessages: + msg260188
2016-02-12 17:40:45socketpairsetmessages: + msg260187
2016-02-12 17:38:26socketpairsetmessages: + msg260186
2016-02-10 22:11:24vstinnersetnosy: + vstinner
messages: + msg260044
2016-02-10 05:28:23socketpairsetmessages: + msg259978
2016-02-10 01:52:05martin.pantersetnosy: + martin.panter
messages: + msg259966
2016-02-09 11:55:30socketpairsetmessages: + msg259928
2016-02-09 06:30:24socketpaircreate