On 6 April 2016 at 16:25, Ethan Furman <et...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
