Trying to construct a Path object from a str subclass, e.g.

class S(str): pass
Path(S("foo"))

fails because the subclass cannot be interned. I think that the interning should simply be removed for non-exactly-str arguments (it is only here for performance reasons, right?), or at least the error should be more explicit (note, in particular, that there is no error if one tries 'Path(S("foo/bar"))' instead, which only confuses the matter more).

In practice, I found out this via numpy, which provides its own str subclass, numpy.str_.

The attached patch should fix the issue.

I'm curious: what is the use case for str subclasses in Path objects?
If this is to be supported, I think I'd rather force-cast to str rather than accept arbitrary subclasses.

I am loading some structure from a MATLAB binary file using scipy.io.loadmat. This structure contains (in particular) paths (written as bytestrings) to other files which end up being loaded as numpy.str_ objects.

In fact, just trying to store and retrieve strings from numpy arrays wraps them in numpy.str_:

>>> import numpy
>>> type(numpy.array(["foo"])[0])
<class 'numpy.str_'>

... and now trying to construct a Path from that will crash.

I agree, though, that force-casting str subclasses in the constructor may avoid other issues.

New changeset c24cbd9bd63b by Antoine Pitrou in branch '3.4':
Issue bpo-21127: Path objects can now be instantiated from str subclass instances (such as numpy.str_).
http://hg.python.org/cpython/rev/c24cbd9bd63b

New changeset aad6d6b819ed by Antoine Pitrou in branch 'default':
Issue bpo-21127: Path objects can now be instantiated from str subclass instances (such as numpy.str_).
http://hg.python.org/cpython/rev/aad6d6b819ed

Ok, I've committed a patch (to 3.4 and 3.5) that force-casts to str.
Thank you for reporting this bug!