[Python-ideas] Dart-like method cascading operator in Python

Haoyi Li haoyi.sg at gmail.com
Fri Nov 22 05:44:14 CET 2013


> But *naming things* is one of the simplest, most powerful techniques for
understanding that human beings have in their mental toolbox

On a philosophical level, there's another simple and powerful technique:
putting things somewhere. Many things are defined entirely by their
location and only incidentally by their name. The city center isn't defined
by the thing called Main Street, but by some vague notion of "there".

> Consider also Python tracebacks, you'll see something like this:

Here's somewhere where I think we disagree. When I see tracebacks, I don't
care what the snippet that caused it looks like in the traceback. I care
about the line number and file name (I don't know how long you spend
looking at tracebacks before going to the file/line). This is my point,
that often the location alone is enough, and the explicit name doesn't help
all that much.

> I expect it will be rather like dealing with one of those conversations
where nobody is ever named directly:

Have you tried reading an essay/paper which doesn't use he/she/it? I have,
and it melts the eyes. Explicitly naming everything instead of using "it"
sometimes does *not* make things more clear!

> People might type + when they mean -, or .. when they mean a single dot,
or a dot when they mean >, or any error at all.

Just because any error has a non-zero change of happening doesn't mean
they're all equally probably. In particular, confusing variable names with
some language-blessed syntax is almost unheard of. Nobody accidentally
shadows *self* in python, or *this* in java, or "_" in scala. Yes, they
can, but it just doesn't happen. n != 0, m != 0 doesn't mean n == m

> That's an argument against using dumb variable names, not an argument for
using variable names.

We're talking in circles though:

- You should name all your variables because naming them short isn't harder
than not-naming them
- We should name them long, because short names are dumb
- We should name them short, because long names are verbose and obscure the
logic.
- GOTO 1

People keep saying "you should do this" and "you should do that", and of
course both the suggestions can solve all problems, except that you can't
possibly apply both suggestions at the same time -.-





On Thu, Nov 21, 2013 at 7:45 PM, Steven D'Aprano <steve at pearwood.info>wrote:

> On Thu, Nov 21, 2013 at 09:48:56AM -0800, Haoyi Li wrote:
> > > Is it really that hard to name a plot "p"? Is typing "p.", or reading
> it,
> > more work than ".."?
> >
> > Yes, reading `..` can be *considerably* less work than reading `p.`.
> > - With `..` you know exactly where the thing is coming from (the
> preceding
> > lines) whereas with `p.`, `p` could come from anywhere
>
> If this argument were good, it would be an argument against naming in
> general. But *naming things* is one of the simplest, most powerful
> techniques for understanding that human beings have in their mental
> toolbox, so much so that people tend to name things which don't even
> exist -- "cold", "dark", "death", "silence" etc. all of which are merely
> the absense of something rather than something.
>
> But I digress. Explicitly named variables are nearly always better than
> implicit, unnamed variables. It's either to talk about "do something
> with foo" than "do something with the thing that you last used". In
> order to reason about such an anonymous implicit block, I reckon that
> most people will mentally translate it into a named variable.
>
> When you have an implicit operand:
>
>     ..method()  # implicitly operates on some unnamed operand
>
> that's rather like having an (invisible) placeholder variable:
>
>     (it)..method()
>
> where "it" is implicitly defined elsewhere. I've used such a language,
> Hypertalk, where you can write code like this:
>
>     get the number of items of field "Counter"
>     put it + 2 into field "Result"
>
> Kind of cool, right? I'm not entirely against the idea. But when you
> have longer blocks of code, it soon becomes painful to keep track of the
> implicit "it", and named variables become much more sensible. What is a
> shortcut for *writing* code becomes a longcut for *reading* and
> *comprehending* code.
>
> If you allow multiple levels of double-dot implicit variables, it
> becomes much harder to track what the implicit invisible variable is
> at any such time. The indentation helps, I agree, but even so, I expect
> it will be rather like dealing with one of those conversations where
> nobody is ever named directly:
>
>   "Then he said that she told him that she went to the party he
>   threw last weekend and saw her there, and he tells me that he's
>   upset that he tried to hit on her and he reckons that she wasn't
>   doing enough to discourage him, but I spoke to her and she
>   reckons it was just a bit of harmless flirting and he's just
>   being unreasonable, absolutely nothing happened between her and
>   him and if he keeps on like this there's be nothing happening
>   between her and him either..."
>
>
> Consider also Python tracebacks, you'll see something like this:
>
> Traceback (most recent call last):
>   File "spam.py", line 123, in <module>
>     main()
>   File "spam.py", line 97, in main
>     func()
>   File "spam.py", line 26, in func
>     ..draw()
> TypeError: draw() takes at least 1 argument (0 given)
>
> In general, I'd much prefer to see the last two lines with an explicitly
> named variable:
>
>     my_artist.draw()
> TypeError: draw() takes at least 1 argument (0 given)
>
>
> but of course that's not available with the .. proposed syntax.
>
>
>
> > - when you're eyes are tired you better look closely to make sure you
> > didn't accidentally write `b` which may mean something else in this scope
> > and cause your program to silently malfunction.
>
> "People might use the wrong variable name if they're coding while tired,
> or drunk, or simply careless" is not a good argument against using
> explicit variable names. People might type + when they mean -, or ..
> when they mean a single dot, or a dot when they mean >, or any error at
> all.
>
> I find it ironic that you are defending syntax that looks like a speck
> of dust on the monitor, or a dead pixel, on behalf of people who have
> tired eyes.
>
>
> > - You also better make sure you didn't have a variable somewhere else
> > called `p` for Pressure in one of your equations which you just stomped
> > over, or `p` for Momentum, or Price, or Probability. It's not
> inconceivable
> > that you'd want to plot these things!
>
> That's an argument against using dumb variable names, not an argument
> for using variable names.
>
>
> > Generally, having fewer things in the local namespace is good hygiene,
> and
> > helps prevent name collisions. This is separate from the issue of the
> > proposed syntax (which I don't really like) and whether it's useful
> enough
> > to warrant special syntax (not sure)
>
> This at least I agree with.
>
>
>
> --
> Steven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131121/da502de3/attachment-0001.html>


More information about the Python-ideas mailing list