[Python-ideas] Better stdlib support for Path objects

[Cathal Garvey]

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

This is a strong solution for new code. A quick hack to fix old code
would be to simply cast the return values from anything returning a
"path" to a string. If it's already a string, it'll be the same string.
If it's a pathlib path, it'll end up a string. That minimises the effort
needed to bring an old codebase up to speed with pathlib while
implementing new code in pathlib, right? And you can work downwards from
there; as long as all callers expecting a path do an explicit str-cast,
you're safe either way?


On 06/10/14 19:29, Guido van Rossum wrote:
> 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.
> 
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

-- 
Twitter: @onetruecathal, @formabiolabs
Phone: +353876363185
Blog: http://indiebiotech.com
miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141006/b95dc567/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141006/b95dc567/attachment-0001.sig>