Being simple vs explicit is a political debate. I prefer if Python has simpler magical syntax.
What are the use cases where you frequently need the index? I write and read a lot of python and I almost never see it. Maybe if you're working in a problem domain where it's a common issue you could create some abstraction to better handle it for you.
It doesn't against ethos of Python. There is a Zens of Python, I don't know Ethos of Python. http://www.python.org/dev/peps/pep-0020/
Beautiful is better than ugly. Writing .items() or surrounding enumerate() does not make your code look prettier, does it?
Explicit is better than implicit. In fact, my proposal is more explicit than the implicit of for key in my_dict or for item in my list. I think returning both key,value are more explicit than say remembering the default return value in looping a dict is a key, not value, or relying on remembering enumerate or items.
It is simpler to write such code, and if you just need one of the return values, just that one, they are named.
You want a use case. I will give you one: find the location of a specific item in the list. and if you use django, you know your template engine can read your psudeo python template code. And you often need that index.
One could just as easily say that your proposal is less explicit, because a sequence is a sequence of items, not (index, item) tuples, yet you're making the "for" iteration yield tuples.
Similarly, a dict is a container of keys, not (key, value) pairs. The reason is that otherwise you would be unable to check to see if a key was in the dict unless you knew the value that went with it: but in that case why would you need the dict? (Technically, you could still iterate over the entire dict looking for your key, but that's extremely slow; the whole point of having a dict is to be able to do fast lookups of keys in order to retrieve their values.)
Writing .items() or surrounding enumerate() does not make your code look prettier, does it?
Neither does having to extract just one item from a tuple when I don't need the index. There's no way around the fact that one of the types of iteration (either just items, or index, item tuples) is going to have to be spelled with something extra. So just saying "I shouldn't have to type something extra" isn't a sufficient argument. You need to justify why your preferred type of iteration should be the one with the shorter spelling: and since your preferred type of iteration has extra baggage attached to it, it seems perfectly legitimate to me that it should have the longer spelling, not the shorter one.
find the location of a specific item in the list
That's what the "index" method is for.
>>> b=['one','two','three','four','two']
>>> b.count("two")
2
>>> b.index("two")
1
>>> b.index("two",2)
4If the best use case you can come up with is the one you've given then we've got real issues. If my team were ever iterating over a list to find the index of an item I would be very upset. That is categorically not the right way to do it.
Regarding the ethos - zen, ethos, call it what you will. Explicit is better. Maybe English isn't your first language but your idea is less explicit than the way it works T te moment.
Consider the following:
menu = [("Apples", 5),
("Cream Pie", 2),
("Tea and scones", 3)]
for food, price in menu:
print "To buy %s, please pay %d dollars" % (food,price)
Right now, it works unambiguously -- just the way you'd expect. The above prints: To buy Apples, please pay 5 dollars.
To buy Cream Pie, please pay 2 dollars.
To buy Tea and scones, please pay 3 dollars.
What if we implemented your rule? Would the intprereter print the above, or would it say this? To buy 0, please pay ("Apples", 5) dollars.
To buy 1, please pay ("Cream Pie", 2) dollars.
To buy 2, please pay ("Tea and scones", 3) dollars.
What if you wanted to print the first one? If your syntax were implemented, the programmer would have to write something awful like for index, (food, price) in menu:
or even for food, price in destructuring_without_index(menu):
which puts us in full circle again!The reason why most of us don't like your idea is because it introduces ambiguity and doesn't even remove the trade-off. No matter how you implement it, there's going to be a trade-off.
The zen of python, by Tim Peters:
Explicit is better than implicit.
Special cases aren't special enough to break the rules.
In the face of ambiguity, refuse the temptation to guess.