[Python-Dev] When should pathlib stop being provisional? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Apr 6 02:52:53 EDT 2016

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

More information about the Python-Dev mailing list