RetroSearch Browse

Tue Nov 4 17:04:00 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/039973.html

On Tuesday 04 November 2003 09:31 pm, Guido van Rossum wrote:
   ...
> option somehow.  But since (a) at least 60% of the examples are
> satisfied with something like irevrange(), and (b) having irevrange()

I'm not sure it's as high as that, depending on how strictly one wants
to define "satisfied".

Say I want to (do some change, say call f() on each item) the prefix of a 
list of numbers, stopping at the first zero I meet.  In old Python:

    for i in xrange(len(listofnum)):
        value = listofnum[i]
        if not value: break
        listofnum[i] = f(value)

but today I'd rather code this:

    for i, value in enumerate(listofnum):
        if not value: break
        listofnum[i] = f(value)

more concise and neat.

So, what if I want to do it to the _suffix_ , the tail, of the list, stopping
at the first zero I meet going backwards?  W/o irevrange, eek:

    for i in xrange(-1, -len(listofnum)-1, -1):
        # usual 3-line body

or equivalently

    for i in xrange(len(listofnum)-1, -1, -1):
        # usual 3-line body

but irevrange would only fix the for clause itself:

    for i in irevrange(len(listofnum)):
        # usual 3-line body

the body remains stuck at the old-python 3-liner.  reversed does better:

    for i, value in reversed(enumerate(listofnum)):
        if not value: break
        listofnum[i] = f(value)

i.e. it lets me use the "modern" Python idiom.

If you consider thise case "satisfied" by irevrange then maybe 60% is
roughly right.  But it seems to me that only reversed "satisfies" it fully.

> > be tossed away.  I would like reversed() to be usable anywhere someone
> > is tempted to write seq[::-1].
>
> Sure.  But is this needed often enough to deserve adding a builtin?

I used to think it didn't, but the more at looked at code with this in mind,
the more I'm convincing myself otherwise.

> If you can prove it would be used as frequently as sum() you'd have a
> point.

No, not as frequently as sum, but then this applies to many other builtins.

> > reversed() is a fundamental looping construct.  Tucking it away in
> > another module in not in harmony with having it readily accessible for
> > everyday work.  Having dotted access to the function makes its use less
> > attractive.
>
> The same can be said for several functions in itertools...

True, but adding ONE builtin is not like adding half a dozen.

> > What's out there now is simple and direct.  Everyone, please accept it
> > as is.
>
> Sorry, I have to push back on that.  We still need to contain the
> growth of the language, and that includes the set of builtins and (to
> a lesser extent) the standard library.  You have to show that this is
> truly important enough to add to the builtins.  Maybe you can propose
> to take away an existing builtin to make room *first*.

I don't know if Raymond has responded to this specific request, but
I've seen other responses and I entirely concur that LOTS of existing
built-ins -- such as apply, coerce, filter, input, intern, oct, round --
could be usefully be deprecated/removed/moved elsewhere (e.g.
to a new "legacy.py" module of short one-liners for apply, filter, ... --
to math for round, oct ... -- legacy could also 'from math import'
the latter names, so that "from legacy import *" would make old 
modules keep working///).

Alex

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/039973.html below:

[Python-Dev] PEP 322: Reverse Iteration