EuroPython 2006 and Py3.0

[Antoon Pardon]

On 2006-07-14, Lawrence Oluyede <rhymes at myself.com> wrote:
> Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>
>> These are just some ideas. Whether they fit into python or not I will
>> leave to the developers.
>
> I'm not a Python pro. but:
>
>> 1) Literal slices, in a sense we already have these, but they are
>>    limited to indexing. You can't do something like fun(::). May
>>    be this means the notation used now has to be adapted.
>
> I don't see the use case for this.

You don't think it usefull that when you need a slice as an argument
you can use the same notation as when you use when you need a
slice as an index?

I have a tree class, a tree acts like a dictionary, but when you
iterate over it, it always iterates over the keys in order. This
makes it usefull to iterate over a slice. So it would be usefull
if methods like keys, values and items could take a slice as
an argument and use the same notation for it. Something like

  for k, v in t.items('a':'b'):

Which would iterate over all items where the key starts with
an 'a'. Sure you don't need it. You could just use 

  for k, v in t.items(slice('a','b')):

or you could define the items method with the same signature
as range or xrange. But it seems appropiate that the same
notation can be used anywhere.

>> 2) Iterable slices. Allow (provided the slice notation stays:)
>> 
>>       for i in (1:10):
>>          ...
>> 
>>    to do the same as:
>> 
>>       for i in xrange(1,10):
>> 
>>   This will allow to get rid of both range and xrange. Xrange
>>   is totally unnecessary and range(a,b) becomes list(a:b).
>
> -1. First: you have to introduce new syntax for an old thing.

That syntax already exists, it just is only available as an
index.

> Second:
> you overload the meaning of slicing and the slice operator and so on.

It's meaning is not overloaded, it just gets extra functionality.

> range is perfectly integrated and the right tool for the job.

Range as it is, is going to disappear. Last time I read the
python 3000 Pep range would get the functionality of xrange
and xrange would disappear, and those who want a list will
have to do: list(range(a,b))

> There's no
> need to introduce new syntax to iterate over a range of integers.

Need is such a strong word. In the end we don't need python, but
it seems very usefull to have it around. I understand that should this
be introduced it could make people uneasy, but I also think it
could be very usefull.

>> 4) Introduce Top and Bottom objects, which will allways
>>    compare greater/smaller to other objects. Make them
>>    the default values for the start and stop values of
>>    slices.
>> 5) Give slices a "&" and "|" operator.
>> 
>> 
>> 7) Give slices the possibility to include the stop value.
>> 
>>    My first idea here was that the notation of slices
>>    was adapted, so that what is a:b now would become
>>    a:|b. A slice to include the b would then be a::b.
>>    You could even have a slice that didn't include the
>>    a but included the b like:  a|:b
>> 
>>    Now I expect a lot of resitance here, so it this
>>    seems not feasable, just drop it.
>> 
>> 6) Is this is all asked too much, make slice at least
>>    subclassable.
>
> Why do you need power slices?

Because it would have made things a lot of easier for me in
a number of cases. I have a table class that is like a
list but can start at any index, it sure would have been
easier to write with some of the possibilities above. I
though to just write my own slice class, but slice is not
subclassable, and when I just wrote my own from scratch,
with a start, stop and step attribute I got an error that
it wasn't an integer so couldn't be used as an index.
So much for duck taping.

But if this idea doesn't catch on, so be it.

-- 
Antoon Pardon