[Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional? (original) (raw)
Ethan Furman ethan at stoneleaf.us
Thu Apr 7 11:33:13 EDT 2016
- Previous message (by thread): [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 04/07/2016 08:18 AM, Paul Moore wrote:
On 7 April 2016 at 15:40, Eric Snow wrote:
On Apr 6, 2016 11:11 PM, "Raymond Hettinger" wrote:
Having worked through the API when it is first released, I find it to be highly forgettable (i.e. I have to re-read the docs each time I've revisited it).
Agreed, though it's arguably better than argparse, logging, unittest, or several other stdlib modules.
Personally, the main issue I have with remembering pathlib method names, is the inconsistency with the existing modules.
That is one of the things I really dislike. If the behaviour is the same as the os version, it should have the same name. I also have no problem with new names that makes more sense so long as an alias exists for the os version (can even be deprecated without removal).
Would I change the names? I honestly don't know. If os.path was going to disappear, then no - the inconsistency is a short term problem. But even if there's a major switch to pathlib, I expect os.path to remain indefinitely, and that inconsistency will be a wart that we'll have to live with for a long time.
os.path isn't going anywhere.
--
Ethan
- Previous message (by thread): [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]