[Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?

[Paul Moore]

On 7 April 2016 at 15:40, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> 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?

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