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

[Haoyi Li]

> Dumb names are dumb because they are misleading, not because they're
short.

p for momentum, pressure or price is not misleading at all. It's standard
terminology in their fields, and when you're writing heavy algebraic code,
writing "momentum" all over the place obscures the logic of your equations.
They're no dumber than `i` as an iterator variable, which suffers the exact
same problem =( I'm not complaining that the names are misleading, I'm
saying they pollute the namespace and cause collisions, unless they're
misleading *because* of their collidiness, in which case I'm accidentally
dumb many times a day.

> The proposed syntax has more to do with "then" rather than "there", that
is, "the last object used", not "the object at location 1234".

I mean "there" meaning "there in the code", not "there in the computer".
It's the lexically-scoped "there", the "there" you're looking at when
you're looking at the source code of the program. I don't care what the
memory location is.

> Out of the infinity of possible errors a tired person might make, why
single out the risk of misusing a named temp variable?

- It's hard to spot "yeah, f = p * a looks right" (p in this scope means
price). You often basically have to do a local dataflow analysis on your
function to spot the problematic scopes.
- Lots of the other errors you brought up can be found by linters, but I
don't know of any linter smart enough to identify misuse of a temp
variable. If it's harder for linters to spot, it's an indication that it's
harder for humans to spot too.
- The interpreter won't throw an exception to tell you you made a mistake,
since it's not a SyntaxError or (often) a TypeError/ValueError
- Often temp variables with the same name often have similar contents,
meaning the program will work fine but silently produce incorrect results =
data corruption yay

I mean, tired people making SyntaxErrors and crashing their process (the
example you gave), or ValueErrors/TypeErrors and crashing production
services, aren't that big a deal v.s. silently corrupting large quantities
of data by sneakily giving wrong answers.

> Funny you say that. I hardly ever pay attention to the line number in
tracebacks

I guess we're different. You don't need to keep repeating to me "code is
read more times than it's written" just because I read code differently
than you =(

> You may need to parse backward all the way to the beginning of the expression
(suite?) to figure out what it refers to.

But with block of code all referring to (setting attributes, calling
methods on) an actual name (e.g. p), you may need to:

- Parse *the entire file and all its imports* to figure out where it comes
from!
- Look closely to make sure the intermediate values of `p` aren''t being
passed around where they shouldn't
- Make sure nobody accidentally sets `p` in between (e.g. [abs(p) for p in
prices] in one of the right-hand-sides)
- Trace p up the block to see how it's being used; is it only having
attributes assigned to? Having methods called on it? Is it being passed in
as a function parameter and the return value being used to replace itself?

With a cascading syntax, you don't need to do any of these things. Yeah,
you could argue that the name should tell you exactly what it does. No, I
don't think that's realistic in practice.

> True, but that is easy enough to get by defining a function.

We'll just have to disagree about the "enough" part. I guess I'm far lazier
than you are =D.

Furthermore, the non-locality of a function call ("where is this function
defined") combined with the visibility ("is this function only being called
here, or at multiple callsites") is a disadvantage when trying to read code.

I'm not wedding for the current ".." syntax; I agree it looks terrible too,
including when python's own RestructuredText does it. In general though,
the fact that cascading is so limited compared to "just assigning a
temporary var" is something I consider a good thing. When I see a cascading
block/expression/whatever, I know immediately what the dataflow looks like:

start
|/ / / /
|/ / /
|/ /
|/
end

With a bunch of inputs coming from the top, joining up with the one
constant implicit "this" on the right. There are no other places where data
is combined. On the other hand, when I see a long block with temporary
variables, maybe the dataflow looks like that, but it could also look like
this:

start
|\ /| /
|/|\|/
|\|/|
|/|\ \
end

With a bunch of variables coming in the top, a bunch of variables going out
the bottom, and a jumble of ad-hoc recombination of everything in the
middle. I then have to construct the dataflow graph in my head before I can
figure out what changes will affect which downstream values, whereas in the
cascading case such truths are self evident.

You could always say "yeah, but that code is sucky spaghetti, it should be
broken up into functions" but you can't say "i never write that", because
in the end we all contribute to the communal pool of sucky spaghetti.

What would be nice are tools to not just express intent (e.g. the identity
context-manager) but enforce it, and I think a cascading operator is one of
those useful tools. No matter how hard a deadline you're under, you can't
just insert extra edges in the cascading-block's dataflow graph without
breaking it up. Someone looking at the cascading-block has a hard-guarantee
that the section of code he's looking at obeys certain strict (and
reasonably intuitive) properties, and doesn't need to spend time tracing
dataflow graphs in his head.

That's why I consider them easier to read.


On Fri, Nov 22, 2013 at 7:44 AM, Chris Angelico <rosuav at gmail.com> wrote:

> On Sat, Nov 23, 2013 at 2:24 AM, Henshaw, Andy
> <Andy.Henshaw at gtri.gatech.edu> wrote:
> > For what it’s worth, if this idea ever gets to the bikeshedding phase...
>
> It gets to that phase the moment it's posted on python-ideas. Have at it!
>
> ChrisA
> _______________________________________________
> 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/20131122/de11dd5d/attachment-0001.html>