On Thu, Mar 30, 2017 at 12:59:57PM +0300, Markus Meskanen wrote:
> And instead of learning a special syntax, which is simple and easy to
> understand when they google "repeat many times python", they now end up
> learning a special semantic by naming the variable with an underscore.
Let me preface this by saying that, *in principle*, I don't mind the
idea of a repeat-without-dummy-variable syntax. I spent a lot of time
programming in Apple's Hypertalk back in the 80s and 90s, and it had
no fewer than five different loop styles:
repeat [forever]
repeat until condition
repeat while condition
repeat with i = start [to|down to] end
repeat [for] N [times]
where words in [] are optional. That last case is exactly the sort of
thing you are talking about: it repeats N times, without creating a loop
variable.
In Hypertalk's case, this worked really well, and I liked it. So I can
say that in principle this is not a bad idea, and it really suits some
language styles.
But not Python.
It works for Hypertalk because it had an already *extremely* verbose and
English-like syntax. A typical piece of Hypertalk code might be
something like this:
add one to total
put the value of num after word 4 of item 3 of line 2 of field 1
For Hypertalk's target demographic (non-programmers who happen to be
doing a bit of programming) it really is better for the language to
provide a close match to their mental concept "repeat five times". The
whole language is designed to work like people think, even when that's
inefficient. I miss it a lot :-)
But Python is a much more general purpose language, and beginners and
non-programmers are only a tiny fraction of Python's demographic. Python
is only English-like compared to languages like Perl or C which look
like line-noise to the uninitiated. So what works for Hypertalk doesn't
necessarily work for Python.
"repeat 5 times" matches the philosophy and style of Hypertalk, but it
clashes with the philosophy and style of Python. Python does not
generally go into special-purpose syntax useful only in a specialised
situation, preferring instead *general* syntax that can be adapted to a
wide-range of situations.
Using _ to mean "I don't care about this name" is general purpose. You
can use it *anywhere*, not just in loops:
# I only care about the side-effects, not the return result
_ = call_function()
# unpack seven items, but I only care about three of them
a, _, b, _, _, _, c = items
And it is optional too! If you don't like the name _ you can use
anything you like:
d = [[0]*5 for whocares in [None]*10]
will create your nested lists for you, and probably ever so slightly
more efficiently than using range().
So even if there's nothing overtly or especially *bad* about adding
specialist syntax to the language, it isn't a great fit to the rest of
Python. And of course any change has some cost:
- more complexity in the parser and compiler;
- more code to implement it;
- more features to be tested;
- more documentation;
- more things for people to learn;
- tutorials have more to cover;
- people writing a loop have one extra decision to think about;
etc. It might not be a *big* cost (it's just one small feature, not an
entire Javascript interpreter added to the language!) but it is still a
cost. Does the feature's usefulness outweigh its cost? Probably not.
It's only a tiny feature, of limited usefulness. At *best* it is a
marginal improvement, and it probably isn't even that.
I'm not saying it isn't useful. I'm saying it isn't useful *enough*.
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
