[asperous]

Explicit is better than implicit.

I think you think for is magical and could be modified like this, but really for just iterates over something. It's enumerate and items that are the magic. Enumerate zips a range onto a list, the ``index,element`` unpacks the zip. Items returns a list of (key,value) tuples and the key,value unpacks that.

You couldn't modify the iterators because it would effect EVERYTHING. sum([1,1,1]) would now be sum([(1,1),(2,1),(3,1)]) AHH! And ``key in dict`` wouldn't work any more, since the iterator would return key,values. EEK.

[yeukhon]

I never said it would be easy to implement or whether it would be actually possible. My complain is that what we are doing right now isn't convenient and is counter-intuitive. I don't write programming language so I wouldn't know how difficult it would be to change the grammar and the semantic of for.

Being simple vs explicit is a political debate. I prefer if Python has simpler magical syntax.

[aidos]

That's totally against the ethos of python. I think you'll find that very few python developers would side with you on that change. If I'm iterating over something I'd like the elements of the thing I'm iterating over, not some weird results based on the type of iterator. In the (extremely) rare cases I need an index I wrap the list/whatever in the enumerate function.

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.

[yeukhon]

Whoever downvoted me have some weird negativity here.

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.

[pdonis]

my proposal is more explicit

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.

[ceol]

I forget if it's Jinja or Django's template, but one of them has a function that only exists inside of for loops that returns the current index. I thought that was a great way to handle it, since it's always available without changing any syntax.

In retrospect, I suppose the .index() method would be fine, since Lists can't hold two of the same object, and Dicts return the key by default.

[pdonis]

Lists can't hold two of the same object

Yes, they can. Try it! The index method has extra arguments to let you specify a range of indexes in the list to search, so you can find multiple indexes that point to the same object (by picking a range that excludes indexes you've previously found).

Dicts return the key by default

Dicts don't have an index method; dict keys are not ordered.

[ghshephard]

I almost never use enumerate in python - 90%+ of the time it's the values I'm interested in - an exception might be if I'm trying to print a numbered list - and it's just handy to have the index instead of incrementing a counter. In your scenario, though, to find the location of a specific item in a list:

  >>> b=['one','two','three','four','two']
  >>> b.count("two")
  2
  >>> b.index("two")
  1
  >>> b.index("two",2)
  4

[yeukhon]

Try building binary search with .index()

[aidos]

I didn't downvote you, but I feel I should. You're suggesting making a magical change to a language because you seem to have failed to grasp the way it works.

If 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.

[gcr]

The reason why Python works the way it does is specifically to keep the magical syntax as simple as possible.

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.

[pdonis]

And ``key in dict`` wouldn't work any more

The "in" operator is actually a separate operator; it doesn't depend on the dict iterator implementation. So you could keep the semantics of the two separate.

However, if the dict iterator semantics were changed, it would make sense to change the semantics of "in" as well--and since it doesn't really make sense to change the semantics of "in" (if you're asking if something is "in" the dict, you mean the key), that would explain why the dict iterator semantics are the way they are: the dict is a container of keys, not key-value pairs.

[zwegner]

I've thought that dict.items() should be the default behavior for a while, but haven't really thought it through. The 'key in dict' example is interesting--is the expected semantics of 'x in y' for sequence types the same as 'any(x == z for z in y)'? That doesn't hold true for strings, as an example.

[pdonis]

is the expected semantics of 'x in y' for sequence types the same as 'any(x == z for z in y)'?

For sequences that aren't strings, yes. :-) Strings are a sort of hybrid between "atomic" values and sequences, so their semantics can be different.