[Python-ideas] Better stdlib support for Path objects

[Antoine Pitrou]

On Mon, 6 Oct 2014 23:30:01 -0400
Donald Stufft <donald at stufft.io> wrote:
> 
> > On Oct 6, 2014, at 9:38 PM, Barry Warsaw <barry at python.org> wrote:
> > 
> > On Oct 06, 2014, at 11:19 PM, Georg Brandl wrote:
> > 
> >> This is like the situation with context managers.  We've taken about 3-4
> >> minor releases to add "with" support to objects that can logically support
> >> it.  Nobody remembers this, so people have to refer to the docs (or the code)
> >> to see if and when e.g. smtplib.SMTP gained "with" support.
> >> 
> >> However, the context managers are a few dozen classes at most.  With paths,
> >> there are hundreds of APIs that would have to be updated to take Paths
> >> in the stdlib alone.  Granted, a good portion would probably work fine since
> >> they only pass through paths to lower level APIs, but still every one has to
> >> be checked.  Going by precedent, that's not something that we would be able
> >> to do consistently, even throughout several releases.  (Another precedent is
> >> Argument Clinic.)
> > 
> > I appreciate that this is a problem with such transitions.  Is it an argument
> > for never doing so though?  Is it better that the stdlib prohibit adoption of
> > advanced features and libraries than to do so piecemeal?  I'm not so sure;
> > even though it's admittedly annoying when such support is missing, it's really
> > nice when they're there.
> > 
> > How useful is pathlib if it can't be used with the stdlib?
> 
> What about C functions? Will they be reasonable to convert them to accept Path instances too?

IMO it's reasonable, but assuming we devise a dedicated protocol for
getting a path's representation (e.g. __strpath__). Concrete type
checking should be avoided.

I hope someone (Barry? :-)) can take the time to think it out.

Regards

Antoine.