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".

Best,
Sven