[Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional? (original) (raw)
Eric Snow ericsnowcurrently at gmail.com
Thu Apr 7 10:40:37 EDT 2016
- Previous message (by thread): [Python-Dev] pathlib (was: Defining a path protocol)
- Next message (by thread): [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Apr 6, 2016 11:11 PM, "Raymond Hettinger" <raymond.hettinger at gmail.com> 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. To some extent the challenge with those is the complexity of the problem space. Furthermore, the key for any sufficiently complex module is that the common-case usage is intuitive and simple enough. Some stdlib modules do a better job of that than others. :/ How much would you say that any of that applies to pathlib? What about relative to other similar packages on the cheeseshop?
Regardless, are there any specific improvements you'd recommend while the module is still provisional? Are your concerns a matter of structure vs. naming? Usability vs. (intuitive) discoverability?
-eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160407/92cb417a/attachment.html>
- Previous message (by thread): [Python-Dev] pathlib (was: Defining a path protocol)
- Next message (by thread): [Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]