Ethan Furman ethan at stoneleaf.us
Wed Apr 6 02:25:59 EDT 2016

• Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
• Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

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.

--
~Ethan~

---

• Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
• Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

More information about the Python-Dev mailing list