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:
>
>> 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'. 
>
> I keep thinking that means changing the meaning of "slice"

Why? This doesn't need any new functionality of slice. I already
can have this behaviour, but just would have to write it as follows:

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

This is just a question of literal slice notation. Do we
limit the notation of a:b to indexing and for the slice(a,b)
notation everywhere else or do we allow the a:b notation for
a slice in other places where it seems usefull.

>> > -1. First: you have to introduce new syntax for an old thing.
>> 
>> That syntax already exists, it just is only available as an
>> index.
>
> Slicing and indexing is inside square brackets. (start:stop) seems
> confusing to me.

The notation is just start:stop the parenthesis will in practice
be added often to avoid disambiguities, like with the compound
statements when the colon is also used to start a suite, a bit
like tuples where parenthesis are often added too, although
they are not really needed to form a tuple literal.

> And I seriously doubt that Guido or someone on his
> behalf will go through introducing another syntax for something that can
> be already done in one way. I came to Python because of it's clean
> syntax and I've always tought "one good way to do one thing" is better
> than Perlish style. That's why I don't like powering up slice objects to
> do that.

My proposal will make the python syntax cleaner. Now you have
slices in python. The general way to have a slice is:

  slice(start, stop, step)

But in one particular place, when used as an index you are allowed
to write that slice as:

  start:stop:step

lst[start:stop:step] is just another way of writing lst[slice(start,stop,step)]

In my opionion that is not very clean. The first part of my proposal
entail no powering up whatsoever. It is just a proposal to make
the syntax of python more clean, so that the start:stop:step notation
for a literal slice is available everywhere, where a literal can
occur, instead of only in one particular place.

>> 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.
>
> I'm not the person in charge to make decisions about Python syntax,
> power and limitations but I really don't see a useful use case to have a
> slice++. Even decorators (that few people really understand) have a lot
> of use cases more than slice++

You should look at my points as different proposals. I think each
proposal is usefull in its own way. Allow the priveleged synax
for indexing anywhere is usefull even if nothing else is accepted.
Allowing slice to be subclassed is usefull even of nothing else is
accepted.  It is not a package deal that is to be accpeted or rejected
as a whole.

>> 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.
>
> I understand. So maybe asking for subclassable slices is better :-)

Well that was one of the things I proposed.

-- 
Antoon Pardon