On 03/29/2016 03:36 AM, Paul Moore wrote:
On 29 March 2016 at 10:43, Michel Desmoulin 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 cannot. Pathlib seems far too complicated to me. (And this coming from the guy whose antipathy [1] path library has both bytes and unicode inheritance and supports 2.7 and 3.3+ in the same code base.)
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.
With antipathy's Path you get either a bPath if the incoming object was from bytes (str in 2.x) or a uPath if it was str (unicode in 2.x). The only problem I have ever hit is with older libraries that were doing type-checks instead of isinstance-checks on their incoming arguments.
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.
If I have to do any other work with the code, then I convert the os.path portions to Path first. It just makes it so much clearer.
But it may be that now is the right time to revisit the choice to not inherit from str.
Is it still marked provisional? The pain of using it with any other portion of the stdlib that uses paths makes it a non-starter for me.
-- ~Ethan~