[Python-ideas] Better stdlib support for Path objects

[Nick Coghlan]

On 7 Oct 2014 04:26, "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.

pathlib is quite high level, so there's a chance of introducing undesirable
circular dependencies in introducing it too broadly.

With ipaddress and, as far as I am aware, pathlib, the intent was for it to
be useful as a manipulation library, but to drop back to a serialised
representation for transfer to other libraries (including the rest of the
stdlib). This helps avoid the monolithic object model coupling that tends
to pervade large Java applications.

If the current spelling of that is too verbose/awkward/error prone, then
I'd prefer to see that tackled directly (e.g. by introducing some
appropriate calculated properties), rather than switching to the highly
coupled all pervasive standard library change we were trying to avoid.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141007/9f616436/attachment.html>