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,