Guido van Rossum wrote:
>
> > On Wed, 9 Aug 2000, Greg Ewing wrote:
> > >
> > > for (x in a, y in b):
> > > ...
>
> No, for exactly the reasons Ping explained. Let's give this a rest okay?
>
> > I would much rather petition now to get indices() and irange() into
> > the built-ins... please pretty please?
>
> I forget what indices() was -- is it the moreal equivalent of keys()?
indices() and irange() are both builtins which originated from
mx.Tools. See:
http://starship.python.net/crew/lemburg/mxTools.html
* indices(object) is the same as tuple(range(len(object))) - only faster
and using a more intuitive and less convoluted name.
* irange(object[,indices]) (in its mx.Tools version) creates
a tuple of tuples (index, object[index]). indices defaults
to indices(object) if not given, otherwise, only the indexes
found in indices are used to create the mentioned tuple -- and
this even works with arbitrary keys, since the PyObject_GetItem()
API is used.
Typical use is:
for i,value in irange(sequence):
sequence[i] = value + 1
In practice I found that I could always use irange() where indices()
would have been used, since I typically need the indexed
sequence object anyway.
> That's range(len(s)), I don't see a need for a new function. In fact
> I think indices() would reduce readability because you have to guess
> what it means. Everybody knows range() and len(); not everybody will
> know indices() because it's not needed that often.
>
> If irange(s) is zip(range(len(s)), s), I see how that's a bit
> unwieldy. In the past there were syntax proposals, e.g. ``for i
> indexing s''. Maybe you and Just can draft a PEP?
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4