Serhiy Storchaka added the comment:
Side comment about "bytes-like" and "byte string". As for language from PEP
484, I think it is too permissive. bytes and bytearray have are "bytes strings"
because they are not only sequences of bytes, but have a lot of str-like
methods: lower(), split(), startswith(), strip(), etc. Many Python functions
that work with "bytes strings" expect the support some of these methods.
memoryview() has no these methods, it is even not always the sequence of bytes.
Other objects that support the buffer protocol can even be not sequences. This
is a problem when we want to support all objects with the buffer protocol in
functions written in Python. We need to wrap them in memoryview and cast to the
'B' format. But in many cases the term "byte-like" means that bytes and
bytearray are accepted. There are different levels of "byte-likelity", and
unfortunately there is no good terminology.
As for moving away from accepting non-bytes paths, I think the arguments are
similar to arguments about why Path is not str subclass. Or why we don't
convert any path argument to string by calling str(). Because it can hide
errors and cause unexpected behavior instead of exception. For example on
Windows array('u', '扡摣晥') represents not Unicode name '扡摣晥', but bytes name
b'abcdef'.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue26800>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
