[Python-ideas] Better stdlib support for Path objects

[Barry Warsaw]

On Oct 06, 2014, at 11:04 AM, Guido van Rossum wrote:

>You can construct a Path from an argument that can be either a string or
>another Path. Example:
>
>>>> from pathlib import Path
>>>> p = Path('/etc/passwd')
>>>> q = Path(p)
>>>> p == q
>True
>>>>
>
>So you could start refactoring stdlib code to use Path internally without
>forcing the callers to use Path, but still *allow* the callers to pass a
>Path. Though I'm not sure how this would work for return values without
>breaking backwards compatibility -- you'd have to keep returning strings
>and the callers would have to use the same mechanism to go back to using
>Paths.

That's a very interesting perspective, and one I'd like to pursue further.

I wonder if we can take a polymorphic approach similar to some bytes/str APIs,
namely that if the argument is a pathlib object, a pathlib object could be
returned, and if a str was passed, a str would be returned.

An example is ConfigParser.read() which currently accepts only strings.  I
want to pass it a Path.  It would be really useful if this method returned
Paths when passed paths (they're used to verify which arguments were actually
opened and read).

There's probably a gazillion APIs that *could* be pathlib-ified, and I'm not
looking to do a comprehensive expansion across the entire stdlib.  But I think
we could probably take a per-module approach, at least at first, to see if
there are any hidden gotchas.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141006/24487f2a/attachment.sig>