On 04/11/2016 09:32 AM, Zachary Ware wrote:
On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote:
If those examples are anywhere close to accurate, an fspath protocol that
supported both bytes and str seems a lot easier to work with.
But why are you working with bytes paths in the first place? Where did
you get them from, and why couldn't you decode them at that boundary?
In 7ish years of working with Python (almost exclusively Python 3) on
Windows and UNIX, I have never used bytes paths on any platform.
I'm not saying that bytes paths are common -- and if this was a
brand-new feature I wouldn't be pushing for it so hard; however, bytes
paths are already supported and it seems to me to be much less of a
headache to continue the support in this new protocol instead of drawing
an artificial line in the sand.
Also, let me be clear that the new protocol will not adversely affect my
own library is it directly subclasses bytes and strings (bPath and
uPath), so they will pass through either way (or be appropriately
rejected if the function only supports str -- are there any?) .
This kind of feels like PEP 361 again -- the vast majority of Python
programmers do not need %-interpolation for bytes, but what a pain in
the rear for those that did! (Yes, I was one of those.) Admittedly,
the pain from this will not be nearly as severe as that was, but why
should we have any unnecessary pain at all?
Asked another way, what are we gaining by disallowing bytes in this new
way of getting paths versus the pain caused when bytes are needed and/or
accepted?
From my point of view the pain of simply implementing this without
bytes support in the existing os and os.path modules is not worth
excluding bytes.
--
~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
