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~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4