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, matrixise, r.david.murray, skip.montanaro
Date 2018-01-18.16:01:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1516291266.66.0.467229070634.issue32594@psf.upfronthosting.co.za>
In-reply-to
Content
I'm not terribly concerned with the end result, only that we wind up with a more consistent system. As I see it, there are two main problems:

1. The type of the name attribute varies

2. The name attribute appears to be undocumented, at least not in the obvious place.

Of lesser importance, but still unintuitive, is that the "name" attribute doesn't refer to an actual name in the filesystem. (I realize that the "name" of sys.std{in,out,err} is also meaningless when interpreted as an actual filename, but that ship sailed long ago.)

I realize that it might well be infeasible to modify behavior at this point. I do think it important to document the "name" attribute (item #2). After all, it doesn't appear to be obviously private.

I live in a Linux-only world, so this workaround in my own code is likely not useful everywhere, but, when I try to convert a builtin file object to an io.TextIOWrapper object using io.open(f.fileno()), I actually do this:

io.open("/dev/fd/{}".format(f.fileno()), ...)

This gives me a meaningful "name" attribute in that it is a string, and that it names an actual filename. How this might work on systems without "/dev/fd", I don't know, but might be worth thinking about for a couple minutes before dismissing it out-of-hand.
History
Date User Action Args
2018-01-18 16:01:06skip.montanarosetrecipients: + skip.montanaro, r.david.murray, docs@python, matrixise
2018-01-18 16:01:06skip.montanarosetmessageid: <1516291266.66.0.467229070634.issue32594@psf.upfronthosting.co.za>
2018-01-18 16:01:06skip.montanarolinkissue32594 messages
2018-01-18 16:01:06skip.montanarocreate