[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