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

[Steven D'Aprano]

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