On 15 April 2016 at 00:52, Stephen J. Turnbull <step...@xemacs.org> wrote:
> Nick Coghlan writes:
>
> > The use case for returning bytes from __fspath__ is DirEntry, so you
> > can write things like this in low level code:
> >
> > def myscandir(dirpath):
> > for entry in os.scandir(dirpath):
> > if entry.is_file():
> > with open(entry) as f:
> > # do something
>
> Excuse me, but that is *not* a use case for returning bytes from
> DirEntry.__fspath__. open() is perfectly happy taking str (including
> surrogate-encoded rawbytes).
That results in a different type for the file object's name:
>>> open("README.md").name
'README.md'
>>> open(b"README.md").name
b'README.md'
Implicitly level shifting in a low level API isn't a good thing,
especially when there are idempotent level shifting commands available
(so you can always ensure a given value is on the level you expect,
even if you don't know which level it was on originally).
I completely agree with you that folks working with text in the binary
domain are asking for trouble, but at the same time, that's the
reality of the way a lot of *nix system interfaces operate. The
guarantee we want to provide those folks is that if they're operating
in the binary domain they'll stay there unless they explicitly shift
out of it using a decoding API of some kind - doing it behind their
back would be akin to implicitly shifting from the time domain to the
frequency domain in an engineering library.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
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
