Path objects cannot be constructed from str subclasses

[anntzer]

BPO	21127
Nosy	@pitrou, @anntzer
Files	pathlib.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-04-22.22:36:11.337>
created_at = <Date 2014-04-01.22:08:28.787>
labels = ['type-bug', 'library']
title = 'Path objects cannot be constructed from str subclasses'
updated_at = <Date 2014-04-22.22:36:11.336>
user = 'https://github.com/anntzer'

bugs.python.org fields:

activity = <Date 2014-04-22.22:36:11.336>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2014-04-22.22:36:11.337>
closer = 'pitrou'
components = ['Library (Lib)']
creation = <Date 2014-04-01.22:08:28.787>
creator = 'Antony.Lee'
dependencies = []
files = ['34759']
hgrepos = []
issue_num = 21127
keywords = ['patch']
message_count = 6.0
messages = ['215342', '215741', '215907', '215936', '217038', '217039']
nosy_count = 3.0
nosy_names = ['pitrou', 'python-dev', 'Antony.Lee']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21127'
versions = ['Python 3.4', 'Python 3.5']

[anntzer]

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

[anntzer]

The attached patch should fix the issue.

[pitrou]

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.

[anntzer]

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.

[python-dev]

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

[pitrou]

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