[Python-Dev] When should pathlib stop being provisional?

[Nick Coghlan]

On 6 April 2016 at 09:45, Guido van Rossum <guido at python.org> wrote:
> On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters
>> <tritium-list at sdamon.com> wrote:
>>> * pathlib should be improved (specifically by making it inherit from str)
>>
>> I'd like to see this specific change settled on in the PEP, actually.
>> There are some arguments on both sides, and some hybrid solutions
>> being proposed, and it looks to be an important enough issue to people
>> for there to be an answer somewhere. It seems to come down to a
>> sloppiness vs strictness concern, I think, but I'm not sure.
>
> This does sound like it's the crucial issue, and it is worth writing
> up clearly the pros and cons. Let's draft those lists in a thread
> (this one's fine) and then add them to the PEP. We can then decide to:
>
> - keep the status quo
> - change PurePath to inherit from str
> - decide it's never going to be settled and kill pathlib.py

Option 4: define a rich-object-to-text path serialisation convention,
as paths are not conceptually the same as arbitrary strings, and we
can define a new protocol accepted by builtins and standard library
modules, while third parties can't

The most promising option for that is probably "getattr(path, 'path',
path)", since the "path" attribute is being added to pathlib, and the
given idiom can be readily adopted in Python 2/3 compatible code
(since normal strings and any other object without a "path" attribute
are passed through unchanged). Alternatively, since it's a protocol,
double-underscores on the property name may be appropriate (i.e.
"getattr(path, '__path__', path)")

The next challenge would then be to make a list of APIs to be updated
for 3.6 to implicitly accept "rich path" objects via the agreed
convention, with pathlib.PurePath used as a test class:

* open()
* codecs.open() (et al)
* io.*
* os.path.*
* other os functions
* shutil.*
* tempfile.*
* shelve.*
* csv.*

The list wouldn't necessarily need to be 100% comprehensive (similar
to the rollout of context management, "support rich path objects in
API <X>" may appear as future RFEs), but it should be comprehensive
enough for rich path objects to mostly "just work" with other APIs
that aren't specifically limiting their inputs to str objects
(although using lower level APIs may force a conversion to the lower
level plain text representation as a side-effect).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia