Other pathlib improvements? was: When should pathlib stop being provisional?
On Apr 6, 2016 11:11 PM, "Raymond Hettinger" <raymond.hettinger@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
On 7 April 2016 at 15:40, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Apr 6, 2016 11:11 PM, "Raymond Hettinger" <raymond.hettinger@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?
Personally, the main issue I have with remembering pathlib method names, is the inconsistency with the existing modules. I always have to check that it's path.is_dir() compared to os.path.isdir(pathstr). And it's os.path.dirname(pathstr) vs path.parent. On the other hand, the consistency between path.parent (for the immediate parent) and path.parents (for the sequence of parents) is useful, so it's not clear cut. There's nothing fundamentally *wrong* with the pathlib method names, but there's no obvious reason why they needed to change. I'll get used to them. It's just one more stumbling block that makes me feel like it's a bit too hard to bother, and I go back to os.path. 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. Paul
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~
Personally, the main issue I have with remembering pathlib method names, is the inconsistency with the existing modules.
Was this *really* not brought up when this was introduced? Oh well. We could add aliases, but I think it's not such a big deal. I'm convinced that the largest barrier to adoption has been that it can't be used with the stdlib. And I think the discussion on Python-ideas supports that. That, and py2 compatibility. There is a back port on PyPi, but it can't be used with the stdlib, either. Not sure what to do about that--maybe it should inherit from Unicode? -CHB
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~
_______________________________________________ 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/chris.barker%40noaa.gov
On 04/07/2016 08:44 AM, Chris Barker - NOAA Federal wrote:
We could add aliases, but I think it's not such a big deal. I'm convinced that the largest barrier to adoption has been that it can't be used with the stdlib. And I think the discussion on Python-ideas supports that.
Lack of interoperability is a huge issue; using different but similar names is still an issue.
That, and py2 compatibility. There is a back port on PyPi, but it can't be used with the stdlib, either. Not sure what to do about that--maybe it should inherit from Unicode?
Also huge, and agree it (the backport) should inherit from unicode. -- ~Ethan~
Le 07/04/2016 16:40, Eric Snow a écrit :
On Apr 6, 2016 11:11 PM, "Raymond Hettinger" <raymond.hettinger@gmail.com <mailto:raymond.hettinger@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.
This is terribly unspecific as far as criticism goes. "Highly forgettable" depends on who you ask. I tend to find unittest and logging quite useful myself, even if I have to look at the docs from time to time (and I'm certainly not the only one). I don't think you'll find an API that doesn't need any learning or getting used, unless it's simply copying another API. os.path() is extremely forgettable as well, but after years of getting used people may feel it's "natural". Put Python in the hands of a non-Python programmer, they will find many things bizarre and uncomfortable compared to their language of choice... Regards Antoine.
On Thu, Apr 7, 2016 at 10:02 AM, Antoine Pitrou <antoine@python.org> wrote:
Having worked through the API when it is first released, I find it to be highly forgettable
This is terribly unspecific as far as criticism goes. "Highly forgettable" depends on who you ask.
Exactly -- for my part, I need to look up most of os.path every time I use it.... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
FYI the doc of the builtin functions is the #1 in stats of docs python.org. I also read this doc every week, even if I consider that I know well Python. IMHO it's not an issue to regulary read the doc. Victor
participants (7)
-
Antoine Pitrou -
Chris Barker -
Chris Barker - NOAA Federal
-
Eric Snow -
Ethan Furman -
Paul Moore -
Victor Stinner