Le 29/03/2016 09:50, Sven R. Kunze a écrit :
On 25.03.2016 22:56, Michel Desmoulin wrote:
Although path.py, which I have been using for years now (and still prefer to pathlib) subclass str and never caused any problem whatsoever. So really, we should pinpoint where it could be an issue and see if this is a frequent problem, because right now, it seems more a decision based on purity than practicality.
I agree. The PEP says:
""" No confusion with builtins
In this proposal, the path classes do not derive from a builtin type. This contrasts with some other Path class proposals which were derived from str . They also do not pretend to implement the sequence protocol: if you want a path to act as a sequence, you have to lookup a dedicated attribute (the parts attribute).
Not behaving like one of the basic builtin types also minimizes the potential for confusion if a path is combined by accident with genuine builtin types. """"
I have to admit I cannot follow these statements but they should have appeared to be necessary back then. As experience shows the PyPI module fared far better here.
I am great a fan of theory over practice as what has been proven in theory cannot be proven wrong in practice. However, this only holds if we talk about hard proof. For soft things like "human interaction", "mutual understanding" or "potential for confusion", only the practice of many many people can "prove" what's useful, what's "practical".
+1. Can somebody defend, with practical examples, the imperative to refuse to inherit from str ? And weight it against the benefits of it ?
We have been doing it for years, and so far it's been really, really nice. I can't recall problem I had because of it ever. I can recall numerous editions of my code because I forgot str() on pathlib.Path.
Best, Sven
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/