On PEP 322 (ireverse)

Alex Martelli aleax at aleax.it
Mon Nov 3 09:25:30 CET 2003

Anna wrote:

> On Mon, 03 Nov 2003 05:01:10 +0000, Dave Benjamin wrote:
>> Pardon me for missing this, but what was the rationale for not just
>> calling it "reverse" and putting it in builtins? And likewise for "sort"?
> reverse and sort already exist in Python, as list methods.
> L.reverse() reverses, in-place, the items of list L.
> L.sort([f]) Sorts, in-place, the items of L, comparing items by f;
> if f is ommitted, cmp is used as comparison function.
> (pg 49, _Python in a Nutshell_)

Yes, the risk of confusion between the existing list methods and the
new functions does play a role in wanting to differentiate their names.

As to whether the new functions (by whatever names) must become
built-ins, that's a separate controversy.  Raymond is keen to have
them as built-ins because he views them as "fundamental looping
constructs".  Guido has decided that list.sorted will be a
classmethod of list instead (more general, one less built-in),
but has essentially approved some reverse-iterating function as a
built-in (and Raymond has vetoed having it as _anything BUT_ a
built-in) so the only issue where debate is allowed (at least
according to Raymond) is on the exact name -- almost.

Almost, because one alternative may still be open: having a
"reversed range" iterator.  I think a built-in 'irange' with an
option to reverse would end up as more generally useful than a
"reverse iterator".  But if the choice is only between either
the reverse iterator, or a revrange iterator builtin, I would
be roughly neutral -- having _three_ built-ins for arithmetic
progressions, with range returning a list, xrange a "neither
fish nor fowl" ``almost but not quite a list // almost but not
quite an iterator'', revrange an iterator, is just too messy to
feel comfortable.  If we introduced a general irange instead
we'd be ready to deprecate xrange soon, _and_ eventually change
range into a simple list(irange(... -- ah BLISS.  Therefore,
to me, introducing irange sounds like a general, clean, wise,
far-seeing approach, while revrange feels too specialized to
"pull its weight" as a built-in.  Oh well.


More information about the Python-list mailing list