Hi, I wanted to do something like i = itertools.chain(list1, list2).index(elem) but that gave me ... AttributeError: 'itertools.chain' object has no attribute 'index' If I use the operator module it works just fine. i = operator.indexOf(itertools.chain(list1, list2), elem) Why not add the index method to iterator objects? Of course, internally only next() is used by the default implementation. -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
On Apr 18, 2004, at 9:53 PM, Christian Stork wrote:
Hi,
I wanted to do something like
i = itertools.chain(list1, list2).index(elem)
but that gave me
... AttributeError: 'itertools.chain' object has no attribute 'index'
If I use the operator module it works just fine.
i = operator.indexOf(itertools.chain(list1, list2), elem)
Why not add the index method to iterator objects? Of course, internally only next() is used by the default implementation.
An iterator mutates each time you call its next(). Your call to indexOf does one of three things: exhaust some of your iterator and return a useless integer, exhaust all of your iterator and raise an exception, or never return. If you want an object that acts like a list, you should use a list. -bob
On Sun, Apr 18, 2004 at 10:08:25PM -0400, Bob Ippolito wrote:
On Apr 18, 2004, at 9:53 PM, Christian Stork wrote:
Hi,
I wanted to do something like
i = itertools.chain(list1, list2).index(elem)
but that gave me
... AttributeError: 'itertools.chain' object has no attribute 'index'
If I use the operator module it works just fine.
i = operator.indexOf(itertools.chain(list1, list2), elem)
Why not add the index method to iterator objects? Of course, internally only next() is used by the default implementation.
An iterator mutates each time you call its next(). Your call to indexOf does one of three things: exhaust some of your iterator and return a useless integer,
Why useless? It returns the index. Why do I have to build a new concatinated list (or my own special index function) in order to get that information?
exhaust all of your iterator and raise an exception,
Yep, just as it would for lists.
or never return.
Well, that's the risk we take with iterators, but in my case I'm certain of two sufficient termination criteria: the iterator is finite and I know that elem is in it.
If you want an object that acts like a list, you should use a list.
I don't see anything inherently "listy" about index(). It just counts how many elements there are to reach elem. And obviously the functionality is already there in the operator module. I'm just proposing a little convenience. -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
On Apr 18, 2004, at 10:21 PM, Christian Stork wrote:
On Sun, Apr 18, 2004 at 10:08:25PM -0400, Bob Ippolito wrote:
On Apr 18, 2004, at 9:53 PM, Christian Stork wrote:
Hi,
I wanted to do something like
i = itertools.chain(list1, list2).index(elem)
but that gave me
... AttributeError: 'itertools.chain' object has no attribute 'index'
If I use the operator module it works just fine.
i = operator.indexOf(itertools.chain(list1, list2), elem)
Why not add the index method to iterator objects? Of course, internally only next() is used by the default implementation.
An iterator mutates each time you call its next(). Your call to indexOf does one of three things: exhaust some of your iterator and return a useless integer,
Why useless? It returns the index. Why do I have to build a new concatinated list (or my own special index function) in order to get that information?
It returns an index into some sequence that no longer exists. What good is that?
exhaust all of your iterator and raise an exception,
Yep, just as it would for lists.
The difference is that the iterator's life is more or less over, there's probably nothing useful you can do with it, but a list is not changed by this operation.
If you want an object that acts like a list, you should use a list.
I don't see anything inherently "listy" about index(). It just counts how many elements there are to reach elem. And obviously the functionality is already there in the operator module. I'm just proposing a little convenience.
I think it's pretty rare that you would want to know this information at the cost of exhausting some/all of your iterator... and if that really is what you want, then you should just use operator.indexOf. There are MANY iterable types, it's not reasonable to change them all. -bob
On Sun, Apr 18, 2004 at 10:50:13PM -0400, Bob Ippolito wrote: ...
Why useless? It returns the index. Why do I have to build a new concatinated list (or my own special index function) in order to get that information?
It returns an index into some sequence that no longer exists. What good is that?
In my special case, it is essentially a ranking. I don't need to access the lists via the index.
exhaust all of your iterator and raise an exception,
Yep, just as it would for lists.
The difference is that the iterator's life is more or less over, there's probably nothing useful you can do with it, but a list is not changed by this operation.
Note that the mathematical function index: Elems -> Integer has a right to live on its own with the application of list accesses. ;-)
If you want an object that acts like a list, you should use a list.
I don't see anything inherently "listy" about index(). It just counts how many elements there are to reach elem. And obviously the functionality is already there in the operator module. I'm just proposing a little convenience.
I think it's pretty rare that you would want to know this information at the cost of exhausting some/all of your iterator... and if that really is what you want, then you should just use operator.indexOf. There are MANY iterable types, it's not reasonable to change them all.
If that is the consensus, so be it. :-) I'm just proposing it as it's in the spirit of itertools. It also eliminates an asymmetry between lists and iterators as demonstrated by operator.index() which is supposed to implement the intrinsic operators. Admittedly, it might not be very common. -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
[Christian Stork]
I wanted to do something like
i = itertools.chain(list1, list2).index(elem)
I'm curious about what application needed to do this.
If I use the operator module it works just fine.
i = operator.indexOf(itertools.chain(list1, list2), elem)
Nice solution. It is general purpose, self-documenting, and efficient. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
On Sun, Apr 18, 2004 at 10:37:28PM -0400, Raymond Hettinger wrote:
[Christian Stork]
I wanted to do something like
i = itertools.chain(list1, list2).index(elem)
I'm curious about what application needed to do this.
It's for a simulation of a peer-to-peer algorithm I'm working on. The lists are lists of peers and could potentially become _very_ large. Therefore concatenation might not be cheap.
If I use the operator module it works just fine.
i = operator.indexOf(itertools.chain(list1, list2), elem)
Nice solution. It is general purpose, self-documenting, and efficient.
Thanks. :-) -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
On Sun, Apr 18, 2004, Christian Stork wrote:
Why not add the index method to iterator objects? Of course, internally only next() is used by the default implementation.
While not entirely off-topic for python-dev, you'll probably get better discussion by going to c.l.py. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "I used to have a .sig but I found it impossible to please everyone..." --SFJ
participants (5)
-
'Christian Stork' -
Aahz -
Bob Ippolito -
Christian Stork
-
Raymond Hettinger