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

[Nick Coghlan]

On 6 April 2016 at 16:25, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 04/05/2016 10:50 PM, Serhiy Storchaka wrote:
>> On 06.04.16 05:44, Nick Coghlan wrote:
>>> 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.*
>>
>>
>> Not sure about os.path.*. The purpose of os.path module is manipulating
>> string paths. From the perspective of pathlib it can look lower level.
>
> The point is that a function that receives a "path" object (whether str or
> Path) shouldn't have to care: it should be able to call os.path.split on the
> thing it received and get back a usable answer.

I actually think it makes sense to pursue this question in a test
driven manner: create "test_pathlib_support" as a new test case, start
passing pathlib.PurePath instances to a relatively high level API like
shutil, and see what low level interfaces need to be updated accept
filesystem path objects (in addition to strings) in order to make that
work. If shutil can be updated to support pathlib with changes solely
at at the io and os module layer, then that bodes well for
transparently enabling support in 3rd party APIs as well.

Cheers,
Nick.

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