<p dir="ltr"><br>
On 7 Oct 2014 19:48, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
><br>
> On 7 Oct 2014 04:26, "Barry Warsaw" <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> ><br>
> > On Oct 06, 2014, at 11:04 AM, Guido van Rossum wrote:<br>
> ><br>
> > >You can construct a Path from an argument that can be either a string or<br>
> > >another Path. Example:<br>
> > ><br>
> > >>>> from pathlib import Path<br>
> > >>>> p = Path('/etc/passwd')<br>
> > >>>> q = Path(p)<br>
> > >>>> p == q<br>
> > >True<br>
> > >>>><br>
> > ><br>
> > >So you could start refactoring stdlib code to use Path internally without<br>
> > >forcing the callers to use Path, but still *allow* the callers to pass a<br>
> > >Path. Though I'm not sure how this would work for return values without<br>
> > >breaking backwards compatibility -- you'd have to keep returning strings<br>
> > >and the callers would have to use the same mechanism to go back to using<br>
> > >Paths.<br>
> ><br>
> > That's a very interesting perspective, and one I'd like to pursue further.<br>
><br>
> pathlib is quite high level, so there's a chance of introducing undesirable circular dependencies in introducing it too broadly.<br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr">Note that a path protocol (with appropriate C API support) would also address this concern with excessive coupling to a specific concrete type.  </p>
<p dir="ltr">A single dispatch generic function as an adapter API would be another option, but would likely pose bootstrapping problems for the lowest level interfaces like os.path and the open builtin.</p>
<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">><br>
> Regards,<br>
> Nick.</p>