Top and Bottom Values [PEP: 326]

[Antoon Pardon]

On 2006-09-27, George Sakkis <george.sakkis at gmail.com> wrote:
> Antoon Pardon wrote:
>
>> What bothers me a bit about the rejection of PEP 326 is that one of the
>> reasons stated is:
>>
>>   http://mail.python.org/pipermail/python-dev/2004-January/042306.html
>>
>>   - it is easily implemented when you really need it
>>
>> Well I thought it would simplify some things for me, so I tried an
>> implementation and then found that some of the things that I would
>> want to do with it wont work. So the "is easily implemented" bit
>> seems not to be correct.
>
> IIRC, the PEP proposed the Smallest and Largest singletons with the
> sole purpose of being used in comparisons. No numeric behavior was
> implied, i.e. Smallest and Largest are not negative and positive
> infinity in the math sense of the word.

That is true.

> So I guess the "easily implemented" refers to this case alone.

This doesn't follow. Take the example were I got stuck.

>>> lst = range(10)
>>> lst[:Top]

This doesn't need arithmetics done with Top. The only fact that
you need is: Top >= len(lst). In a way this isn't that difficult
in itself, it becomes difficult because python doesn't allow
ducktyping for a lot of its builtins. I could write my own
function:

  def leftslice(lst, num):
    return  [ tp[1] for tp in enumerate(lst) if tp[0] < num ]


This function works as expected if you substituted Top for num
and as you can see, no arithmetic is done on num, only comparisons.

-- 
Antoon Pardon