[Python-ideas] Better stdlib support for Path objects

[Guido van Rossum]

On Mon, Oct 6, 2014 at 11:24 AM, Barry Warsaw <barry at python.org> wrote:

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

Sounds like a plan. I'd like to see how hard it is in practice to do the
polymorphic return value thing.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141006/d62c900f/attachment.html>