Top and Bottom Values [PEP: 326]

[Antoon Pardon]

On 2006-09-28, Georg Brandl <g.brandl-nospam at gmx.net> wrote:
> Antoon Pardon wrote:
>> 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]
>
> FWIW, this works with 2.5 and the __index__ slot:
>
> >>> class Top(object):
> ...  def __index__(self):
> ...   return sys.maxint
> ...
> >>> a=range(5)
> >>> a[:Top()]
> [0, 1, 2, 3, 4]
> >>>

It is something worth investigating, but I'm not sure it
will suite my purpose. You see I have a table module,
a table is like a list except the base index doesn't need
to be 0. So I could have a table that is indexable from
sys.maxint - 3 to sys.maxint + 7. I'm not sure tbl[:Top]
would do what it is supposed to do in those circumstances.

-- 
Antoon Pardon