What about an EXPLICIT naming scheme for built-ins?

[Alex Martelli]

On 2004 Sep 04, at 22:35, Carlos Ribeiro wrote:

...lots of interesting things snipped to focus on one pet peeve of 
mine;-)...:

> list (more on this later). As for reversed(), a simple idiom can be
> used to return a new, reversed list:
>
> reverse_list = [x for x in reversed(mylist)]

Or, vastly better IMHO, one could equivalently code.

reversed_list = list(reversed(mylist))

I don't understand why some people want to use list comprehensions 
instead of simple calls to list().  I feel the latter is more readable 
and more concise at the same time.  Moreover, I understand that 
worrying about such things as performance is uncouth, but, on my 
old-ish 12" iBook with Python 2.4 alpha 3:

$ python ~/cb/timeit.py -s'r=range(1000)' 'list(reversed(r))'
10000 loops, best of 3: 99 usec per loop

$ python ~/cb/timeit.py -s'r=range(1000)' '[x for x in reversed(r)]'
1000 loops, best of 3: 706 usec per loop

Dunno 'bout you guys, but I can't really afford to throw away a factor 
of SEVEN in a perfectly ordinary task in such a fashion...

> To put the question bluntly, **is there any reason to implement either
> isorted() or reversed()**? The arguments (pro and against) are as
> follows:
>
> PRO:
> -- it's possible, and relatively easy to implement
> -- completeness
> -- consistency
> -- native implementation would perform better in some cases
> -- the existing idioms may not be immediately clear to the novice (see
> example above)

I think the existing idiom list(reversed(seq)) is perfectly clear to 
the novice and there would be no very significant performance gain in 
having one builtin doing both.  isorted is a different case, not 
trivial for the novice to implement.  However, I suspect that the use 
cases for isorted are typically the same as those for my own pet 
accumulator function (which isn't in the builtins, nor anywhere in the 
standard library -- so far...), top(N, seq), which IMHO should return a 
list (of length min(N, len(seq)) -- seq doesn't need to support 
len(seq) but I hope this pseudocode is clear anyway;-).  I'm not sure 
the performance for a direct implementation of top(N, seq) can 
substantially beat list(itertools.islice(isorted(seq), N)), but, if I'm 
right in thinking that 'top' covers most use cases for isorted, then 
clearly it's more concise than the idiom based on isorted and islice, 
way clearer to novices, AND can get _at least_ marginally better 
performance.  [[of course top, like isorted, should have the same key= 
and reversed= keywords as sorted and list.sort, and so should heapq 
even though sadly currently it doesn't, but, anyway, the assumption 
that reversed= is there is why I don't worry about whether we're 
getting the highest N _or_ the lowest N items...:-).

> AGAINST:
> -- just because it's possible does not means that it's a good idea
> -- more bloat in the standard library
> -- more builtins to pollute the namespace
> -- more thing for a novice to learn
> -- quoting Alex Martelli: practicality beats purity

I was of course quoting Tim Peters -- try:
    >>> import this
at any interactive Python prompt to get all of his "Zen of Python" 
(recommended -- Anna and I even chose it among our marriage's readings, 
together with Petrarca, Lucretius, Blake, and Dickinson...!-)

>
> Given the arguments, I agree that it's better to leave it as it is
> (but changing the name of reversed() to ireversed(), as proposed on
> (1)).

I see your point about the name change, but: you have about 2-3 weeks' 
time to convince _Guido_ (once Python 2.4 is out of alpha and into beta 
it's too late!), and thus you should be posting on python-dev, as he 
doesn't read c.l.py any more -- I suggest you write up the name change 
part only, concisely, and post to python-dev... you do have a chance to 
convince him, at least if Raymond Hettinger (python's current iteration 
guru, inventor of both reversed and itertools and chief implementor 
thereof, among many other precious contribution to the last few Python 
versions!) sees things your way.  I would suggest you traipse the 
python-dev archives for a few months' back before you write there, 
because the issue of reversed's naming WAS discussed before Raymond 
added it to CVS, so your thesis will be more convincing if it 
acknowledges and rebuts the arguments against it, too.


> A sorting generator is useful IF:
>
> -- you know you aren't going to need the entire sorted list;
> -- just a few elements will do.
>
> A particular situation is where you don't know in advance exactly how
> many elements you need; in this case, a sorting generator is probably
> the best approach.

If you have a reasonably tight upper bound on the number of elements 
you may need, 'top' will still beat 'isorted'.  I can't think of a use 
case where I would NOT have such a bound -- can you suggest some?


> My best bet, now, is writing a cookbook solution to implement a
> "pseudo-sort-generator" using the heapq library. It's a good proof of
> concept, and may help to illuminate the question with a practical
> tool.

We _do_ have one, by the way:

<recipe id="280501">
    <title>Lazy sorting</title>
    <authorfirst>Matteo</authorfirst>
    <authorlast>Dell'Amico</authorlast>   <updated>2004/05/03</updated>

...(rest snipped, look it up for yourself;-)...

>
>
> p.s.:
>
> [Alex Martelli]
>> If you hadn't responded publically I'd never would have
>> got a chance to object, so of course I don't mind!-)
>
> It's always a pleasure to have you participating, even after you have
> effectively killed most of my arguments :-) I just feel honored ;-)

Why, thanks!  The one argument I can't "kill" is the one for ireversed 
as a better name than reversed; I don't know if you're right or wrong, 
your arguments make sense to me but so do the counter-arguments that 
were hashed forever on python-dev months ago...


Alex