What about an EXPLICIT naming scheme for built-ins?

Alex Martelli aleaxit at yahoo.com
Sat Sep 4 11:00:28 CEST 2004

Carlos Ribeiro <carribeiro at gmail.com> wrote:

> Mostly agreed. There is an inconsistence, as sorted() and reversed()
> should return both the same type of result - be it a sequence or a
> iterator.

"A foolish consistency is the hobgoblin of a small mind" (Emerson?) or
something like that.  reversed doesn't NEED to build a sequence in
memory so it's fit and proper that it returns an iterator.  sorted DOES
need to build a new list in memory, so it would be a waste to have it
return an iterator on the list (no gain if you're only looping, a net
loss if you're going to call 'list(sorted(foolist))'... a black eye to

> 1) sorted() and reversed() should return sequences. So sorted() stays
> like it, and reversed() meaning is changed. Now, that could
> potentially break a lot of code, but probably this is not going to
> happen -- because in most situations, reversed() is getting called

It's not going to break MUCH code ("just" that relying on being able to
call .next() on reversed's value) and if breakage should be needed now
(before alphas turn to betas) is THE time.  But the issue is another:
wanton waste of memory pursuing "a foolish consistency".  Practicality
beats purity.

> 2) add two new builtins, called respectively xsorted() and
> xreversed(), as the iterator versions of sorted() and reversed(). This
> way we keep the existing naming convention for range() and xrange().

That naming convention is one of Python's warts and the LAST thing we
want is to reinforce it.  Note that the names in itertools all start
with 'i', sensibly, not with an absurd 'x' to honor xrange!

> > <opinion>
> > I would like to see Python introducing a naming scheme for built-ins. Ruby
> > for example uses the ! to indicate an in-place function [sort() vs.
> > sort!()]. I know, that the exclamation mark is out of discussion but I
> > would appreciate to have a clear and distinct function naming (Explicit is
> > better than implicit).

I agree -- that was one of the several things I liked in Prothon's (RIP)
changes over Python: bang and question allowed as the LAST character of
an identifier (only), with the universal convention of bang meaning
"modifies arguments" (typically the implied argument 'self') and
question meaning "returns a boolean value" (a predicate, in other
words).  Maybe there's a hope for that in Python 3.0 (would break no
code: bang is only a prefix operator, question is not a character Python
uses at all currently).

If we can't have bang and question I doubt any other convention is worth
the bother.


More information about the Python-list mailing list