[Python-ideas] __dir__ in which folder is this py file

[Steven D'Aprano]

On Mon, May 07, 2018 at 11:42:00AM +0000, Nathaniel Smith wrote:
> On Mon, May 7, 2018, 03:45 Steven D'Aprano <steve at pearwood.info> wrote:

[...]
> > So yes, its very distracting.
> 
> Well, yes, you do have to know the API to use it, and if you happen to have
> learned the os.path API but not the pathlib API then of course the os.path
> API will look more familiar. I'm not sure what this is supposed to prove.

Apologies for not being more clear.

I'm arguing that for some people, your preferred syntax *is* more 
distracting and hard to comprehend than the more self-descriptive 
version with named functions. And its not just a matter of *learning* 
the API, it is a matter of using it so often that it ceases to look 
weird and looks natural.[1]

There's a school of thought that says that operator overloading is a bad 
idea, that operators should never be overridden to do something aside 
from their common meaning (e.g. + should always mean plus, / should 
always mean numeric division, etc).

>From that perspective, using / to mean something kinda-sorta like string 
concatenation, only path separator aware, is precisely the sort of thing 
that makes some people dislike operator overloading.

http://cafe.elharo.com/programming/operator-overloading-considered-harmful/

https://blog.jooq.org/2014/02/10/why-everyone-hates-operator-overloading/

I am not going to go quite that far. I think operator overloading has 
its uses. I'm not going to argue that pathlib's use of / was "bad" or a 
mistake or harmful. I called it *weird* and that's as far as I'll go. I 
use lots of weird things, and I even like some of them.

But if you think it isn't distracting, I think you are mistaken, and I 
think we ought to show caution in making it a built-in or an offical 
part of the module API.

Your earlier comment (which I redacted):

    Hmm, the feedback I've heard from at least some folks teaching
    intro-python-for-scientists is like, "pathlib is so great for
    scripting that it justifies upgrading to python 3".

felt to me awfully close to

    "pathlib! it's the future!"

I know that's not what you said, or even meant, but I felt it was 
important to remind people that not everyone knows pathlib or finds its 
API clearer than the explicitly named functions of os.path.

joinpath() may be longer than / but it is self-descriptive and easier to 
look up. help(joinpath) will tell you exactly what it does. help("/") is 
almost surely going to talk about numeric division, and it probably 
won't even mention strings or path objects at all.

I say that because we've had + for string concatenation since way back
in Python 1.5 or older, and yet as late as 3.6 help("+") still doesn't
say a thing about string, list or tuple concatenation.

As a Linux user, I'm used to paths containing slashes:

    $HOMEDIR/spam/eggs

but putting quotes around the components looks unusual and is a hint
that something usual is going on (namely a shell escape). But writing
something like:

    HOMEDIR / "spam" / "eggs"

doesn't even look like a path, just looks *wrong*. It looks like I'm 
escaping the wrong parts of the path: instead of escaping the spaces, 
I've escaped the parts with no spaces.

It looks wrong as a Linux path, it looks wrong as a Windows path, and it 
looks wrong as division. So, yes, it is distracting.

I'm not saying that everyone will feel the same way, or that I cannot or 
will not learn to accept / as I've learned to accept % for string 
interpolation despite it looking like percentage. But I'm saying it's 
not a slam-dunk useability win to move to pathlib.


> > First I have to work out what __filepath__ is, then I have to remember
> > the differences between all the various flavours of pathlib.<whatever>Path
> > and suffer a moment or two of existential dread as I try to work out
> > whether or not *this* specific flavour is the one I need. This might not
> > matter for heavy users of pathlib, but for casual users, it's a big,
> > intimidating API with:
> >
> > - an important conceptual difference between pure paths and
> >   concrete paths;
> > - at least six classes;
> >
> 
> The docs could perhaps be more beginner friendly. For casual users, the
> answer is always "you want pathlib.Path".

That might be what I want, but it isn't what I get:

py> p = pathlib.Path('/')
py> p
PosixPath('/')

I know what a PosixPath is. But the point is, even beginners have to 
deal with the complexity of the pathlib API the moment they print a path 
object in the interactive interpreter.



[1] I've been using % for string interpolation for two decades now, and 
it still looks like a misplaced percentage sign every single time.


-- 
Steve