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

Steven D'Aprano steve at pearwood.info
Fri Nov 22 07:05:56 CET 2013


On Thu, Nov 21, 2013 at 08:44:14PM -0800, Haoyi Li wrote:
> > 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".

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


> > 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.

Funny you say that. I hardly ever pay attention to the line number in 
tracebacks. Most of the time, seeing the immediate call and the relevant 
line of code is enough for me to zero in on the relevant section ("ah, 
that failure is in the foo function...."). Almost the only time I care 
about the line number is when debugging code that I'm not familiar with.

But that's okay. I'm not proposing that we strip line numbers just 
because they're of minimal use to me. I understand that they're of use 
to some people, and even of me sometimes. So line numbers help in 
debugging. So does printing the actual line of source code. In the 
interactive interpreter, where it is not available, I often miss it. 
Consider:

    gunslinger.draw()  # looks obviously correct

    artist.draw()  # looks obviously incorrect, a drawing needs a subject

but:

    ..draw()  # no idea


One of the costs, and in my opinion a severe cost, of this proposed 
syntax is that it encourages a style of writing code which is optimized 
for writing instead of reading. We write code much more often than we 
write it.


> > 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.

You've deleted the context of my objection. You objected to the obvious 
solution of a temporary variable name (say, p) on the basis that when 
the coder is tired, he might write:

p = MyClass()
p.spam()
b.eggs()

by mistake. True, but he also might write:

p = MyClass(
    ..spam()
    .eggs()
# and somewhere further down the code base
)

The "tired programmer" objection can be applied to *anything*. I've 
written . instead of , when tired, **args instead of *args, 
length(mylist) instead of len(mylist), and just about every error a 
programmer can make. Out of the infinity of possible errors a tired 
person might make, why single out the risk of misusing a named temp 
variable?


> Nobody accidentally
> shadows *self* in python,

I've seen plenty of code that shadows self.


> 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

No. It depends on the name. "for i in range(100)" is fine, i as an 
integer variable is fine. i = MyClass() is not. Dumb names are dumb 
because they are misleading, not because they're short.

> - We should name them short, because long names are verbose and obscure the
> logic.

I've certainly never made that argument. It is possible to have names 
which are too long, but that's a style issue. Don't call something 

the_variable_holding_an_integer_value

when "myint" or even "i" will do.


-- 
Steven


More information about the Python-ideas mailing list