On 04/08/2016 04:05 PM, Koos Zevenhoven wrote:
On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote:
On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote:
At this point no one wants to touch bytes paths. If you need that level of
control because of multiple encodings within a single file system then you
will probably have to stick with managing bytes paths on your own to get the
encoding right.
What does this mean? I assume you don't mean os.path.* would stop
dealing with bytes?
No, it does not mean that. It means the stuff in place won't change,
but the stuff we're adding now to integrate with Path will only support
str (which is one reason why os.path isn't going to die).
And if not, then you seem to mean that os.fspath
would do nothing except call .__fspath__().
Fair point. So it should be something like this:
def fspath(thing):
# look for path attribute
string = getattr(thing, '__fspath__', None)
if string is not None:
return string
# not found, do we have a str or bytes object?
if isinstance(thing, (str, bytes)):
return thing
raise TypeError('`thing` must implement the __fspath__ protocol or
be an instance of str or bytes')
And just because DirEntry supports bytes doesn't mean that any magic method
it gains has to carry that forward (it can always raise a TypeError if
necessary).
No, but what if some code gets pathnames from whatever other places
and passes them on to os.scandir. Whenever it happens to get a bytes
path, a TypeError gets raised, but only when it picks one of the
DirEntry objects and for instance tries to open(...) it. Of course,
I'm not sure how common this is.
Yeah, I don't think this is a good idea. Given that fspath() should be
able to return bytes if bytes are passed in, DirEntry's __fspath__
could return bytes to no ill effect.
I realize this may not be ideal, but throwing bytes to the wind is going
to bite us in the end.
After all, the idea is to make these things work with the stdlib, and
the stdlib accepts bytes for path strings.
--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
