Skip Montanaro <skip.montan...@gmail.com> added the comment:
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.
----------
_______________________________________
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
