[Python-ideas] Working with Path objects: p-strings?

Michel Desmoulin desmoulinmichel at gmail.com
Tue Mar 29 06:57:02 EDT 2016



Le 29/03/2016 12:36, Paul Moore a écrit :
> On 29 March 2016 at 10:43, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
>> +1. Can somebody defend, with practical examples, the imperative to
>> refuse to inherit from str ? And weight it against the benefits of it ?
> 
> I don't intend to get sucked into the role of "defender of not
> inheriting", but one point that should probably be considered is that
> on Unix, it is possible to have paths which are *not* valid Python
> strings. How would those work in an inherit-from-str environment? I
> suspect that using surrogateescape is the answer here, but I don't
> know.

How does str(path) does it ? Because ultimatly, we pass strings to
open() and os.stuff. So we need it as strings anyway.

> 
> Also, has anyone *converted* code from os.path manipulation of strings
> to a str-subclass path object like path.py? If you write your code
> from scratch intending to use path.py it's probably easier to avoid
> objects getting silently downgraded from path to str than if you're
> retrofitting a path library to legacy code. That's a consideration
> that is more applicable to the standard library than to a 3rd party
> module.

I do it all the time. I'm a path.py/begin/request/arrow/pytest addict
and try to convert coworkers as I meet them, so for path.py I'll usually
take a small part of their project with intensive FS manipulations and
demonstrate how path.py integrate in it.

It's doesn't take a lot to convince them, the one good reason people
don't want to is the additional dependency, which I understand
perfectly. The only hard part to sell is the need to always pass unicode
strings to Path(), because in Python 2.7 it tries to automatically
convert b'' to u"" with the usual UnicodeDecodeError pitfalls.

It's a good habit anyway, yet people are attached to their shortcuts :
it's the same with arrow because of the default to UTC instead of local
time.

it's the same with pytest which requires python setup.py develop and
explicit -s.

request and begin are is easier since urllib and argparse are so hard.

Like with all changes, you need a little adaptation.

But all in all, HTTP requests, FS manipulation, datetime handling, unit
tests and parameter parsing are so common tasks it make sense to have
tools that gets the job done in a few lines and gets out of the way. You
want to concentrate of the real value of your code, not those.

Now I was sad when I learned request would never be part of the stdlib,
and I'm still sad asyncio doesn't have a good way to do a simple GET
with the stdlib, even more with http2 comming our way.

But I get it: the web moves was, the stdlib moves slowly.

It's not True with FS manipulations, they are are old as it gets, and we
can improve on them without fearing to be left behind.

> 
> But it may be that now is the right time to revisit the choice to not
> inherit from str. I don't know, personally. I'm not even sure if a
> pathlib.Path that inherited from str is something I'd use more often
> than I currently do. For open source work, the need to support Python
> 2 means I can't use pathlib (without adding the backport as a
> dependency). For personal code, it's just a case of mental inertia...
> 
> Paul
> 


More information about the Python-ideas mailing list