[yeukhon]

The one thing I wish they could change in the future is forcing list and dictionary iterable same syntax:

instead of writing

for index, element in enumerate(some_list)

for key, value in my_dict.items()

they should unify and make items and enumerate default behavior. i.e.

for index, element in my_list:

for key, value in my_dict:

I really don't see the benefit of not doing this as default behavior. I always find if I need to loop a list there is a good chance the index can help, and even if I don't need it it doesn't hurt to have one either. Simple is better. And the whole looping dict and get back the key only sucks too because you often need the value as well so you essentially do dict["key"] but why not just default return both key and value?

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

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

[pdonis]

I always find if I need to loop a list there is a good chance the index can help

You may always find this, but lots of people don't. I find myself doing lots of iteration that doesn't need the index.

and even if I don't need it it doesn't hurt to have one either

Yes it does, because you're adding extra code to compute the index to every iteration, whether it's needed or not. It's not a good idea to encumber such a basic language construct with any extra baggage; that's why the extra baggage is in "enumerate", so you only get it if you actually need it.

[meowface]

First, keep in mind that as others have said, there is no "magic" involved here.

`list(seq)` will return a list of elements. `list(dct)` will return a list of keys. A for-loop will always loop over the abstract "list representation" of the object (the list result itself is just an accumulation of values from a for-loop).

So your first suggestion would make no sense whatsoever. As for the second...one could maybe argue for that. Many people end up using `dct.keys()` anyway when they want the keys, and `.items()` is so common that it could maybe be made the default. Ruby actually does this by default. However, it would break a ton of current code where people expect to be looping over the keys.

[chilldream]

If you're proposing that I can write either `[x for x in X]` for iterating without indices and `[i,x for x in X]` (or `[i,x for i,x in X]` then you introduce ambiguity (what if it's a list of 2-tuples?). If you mean that I always have to write `[i,x` etc even if I don't need the indices then that introduces a lot of noise for the distant minority case.

Dictionaries also have the same ambiguity problem (tuples can be dictionary keys). The noise problem is a bit more justified, but the entire construct is less needed since `D[k]` is less clunky and error-prone than `L.index`.

[kansface]

my_dict is a dictionary while items() and friends return an iterable. Your proposed change would lead to ambiguity and confusion- what determines how we should iterate (what does it return, when is it done)? How would we define custom iterables?