I love this. So simple and smooth. But what happens if we need also
the position of an object in a list. Then there comes this annoying
writing.
>>> for i in range(len(a)):
>>> print a[i], i
>>>
1 0
2 1
3 2
4 3
I think that it would be great if the Python language, which is a
totaly OOP language, could also use the index variable from the first
example and consider it as an object with a Object variable. I mean
the following.
>>>for i in a:
>>> print i, i.index # i.index is my sugesstion
>>>
1 0
2 1
3 2
4 3
I think that this would be great and we cou pass by this annoying
"range(len(a))" functions
Luckily for those who read either the documentation or this form regulary,
the solution is already there (since python2.0 or so...)
for i, item in enumerate(iterable):
...
does the trick.
Diez
for index, obj in enumerate(any_sequence):
print "obj %s is at position %s" % (obj, index)
print "And I might read the FineManual(tm) some day..."
HTH !-)
Oh, and while we're at it:
> I think that it would be great if the Python language, which is a
> totaly OOP language, could also use the index variable from the first
> example and consider it as an object with a Object variable. I mean
> the following.
>
>>>> >>>for i in a:
>>>> >>> print i, i.index # i.index is my sugesstion
Python is 100% OO in that everything (at least everything you can bind
to a name) is an object. But it doesn't mean everything has to be done
using the dotted syntax...
Adding a random new attribute to arbitrary objects any time they happen
to end up in a for loop would be catastrophically terrible. Consider
the enumerate builtin, instead.
>>> for i, e in enumerate('abcd'):
... print i, e
...
0 a
1 b
2 c
3 d
Jean-Paul
But the added complexity of your approach of setting an attribute at runtime
that can
- add arbitrary costs (who knows that setting the attribute might not
invoke a RPC-call?) for *every* enumeration of a list
- conflict with multithreaded access or even only cartesian products of the
same list of objects, rendering it simply useless
is *less* hassle than putting a simple enumerate in place, just when needed?
You sure have an interesting view of complexity. Not exactly text-book-based
though.
Diez
"enumerate" doesn't add complexity: it adds specificity. When you use it,
there is no question of intent. You are saying, explicitly, that you're
going to want to use the index.
Your way adds an enormous amount of complexity in that it's magic behavior
with no obviously good implementation. What if the objects in my list
already have an attribute named "index" and I don't want your loop
contstruct to overwrite it? What if I never use enumerate as it is and
don't want to pay for the extra overhead of modify every object I'll ever
get from an iterator?
Thanks, but no. One of the things I love about Python is its lack of magic.
--
Kirk Strauser
The Day Companies
Agreed. Enumerate works everywhere an iterable is wanted.
Just like other functions that produce iterables.
A special trick for for-loops would only work for for-loops.
> I know that. enumerate is a great function. But this way it always
> adds some complexity.
That objection doesn't really make sense. Your suggestion is far more
complex: It requires that an `index` attribute be added to every
element in an iteration. What's the lifetime of that attribute? Is it
a real attribute, permanently attached to the item? What about for
objects that already have an `index` attribute? If it's a "virtual"
attribute, how long does it last? Is the iterated object a
newly-created wrapper object for the purposes of providing that
attribute? If so, how do you make that more efficient than just
creating a new object for each object you iterate over? And so on.
Just use `enumerate`. That's what it's there for.
> I think that it is more better to give a man a
> better tool then to let him play with a not so good one. People like
> Python because of his simplicity in comparison with c++. Maybe People
> would like him even more it would be a bit more simple but the same
> powerfull.
The problem is your suggestion would make Python a worse tool, not a
better one.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
Triumph cannot help being cruel.
-- Jose Ortega y Gasset