Top and Bottom Values [PEP: 326]
Antoon Pardon
apardon at forel.vub.ac.be
Thu Sep 28 02:59:50 EDT 2006
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
More information about the Python-list
mailing list