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/

Reply via email to