On 18/02/17 19:35, Mikhail V wrote:
You mean what my proposal would bring
technically better than e.g.:
for i,e in enumerate(Seq)
Well, nothing, and I will simply use it,
with only difference it could be:
for i,e over enumerate(Seq)
In this case only space holes will be
smoothed out, so pure optical fix.
But you also make the language's structure not make sense. For good or
bad, English is the language that the keywords are written in so it
makes sense for the Python language constructs to follow English constructs.
An iterable in Python (something that can be the target of a 'for' loop)
is a collection of objects (whether they represent a sequence of
integers, a set of unique values, a list of random things, whatever).
It is valid English to say "for each object in my collection, I will do
the following:".
It is not valid English to say "for each object over my collection, I
will do the following:".
In that respect, "in" is the correct keyword for Python to use. In the
physical world, if the "collection" is some coins in your pocket, would
you say "for each coin over my pocket, I will take it out and look at it"?
Other than that, I also echo Stephen's comments that not all iterables'
lengths can be known in advance, and not all iterables can be indexed,
so looping using length and indexing is a subset of what the 'for' loop
can do today.
Why introduce new syntax for a restricted subset of what can already be
done? Soon, someone else will propose another syntax for a different
subset. This is why people are talking about the "burden" of learning
these extra syntaxes. Rather than 10 different syntaxes for 10 different
subsets, why not just learn the one syntax for the general case?
E.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
