Le 29/03/2016 12:36, Paul Moore a écrit :
On 29 March 2016 at 10:43, Michel Desmoulin desmoulinmichel@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