slice notation as values?

Antoon Pardon apardon at forel.vub.ac.be
Sat Dec 10 11:43:31 EST 2005


On 2005-12-10, Duncan Booth <duncan.booth at invalid.invalid> wrote:
> Antoon Pardon wrote:
>> In general I use slices over a tree because I only want to iterate
>> over a specific subdomain of the keys. I'm not iterested in make
>> a tree over the subdomain. Making such a subtree would be an
>> enormous waste of resources. 
>
> Probably not unless you have really large data structures. If you have 
> something like a dbhash which would be inefficient to copy then both the 
> original view of the data structure and the slices could share the same 
> data. Creating a slice doesn't *have* to copy anything just so long as the 
> semantics are clear.
>
>> With slice notation you could have the following two cases:
>> 
>>   for key in tree.iterkeys('a':)
>> 
>>   for key in tree.iterkeys(:'b')
>
>  x['a':] is short for x['a':None]
>  x[:'b'] is short for x[None:'b']

That is beside the point. The user doesn't have to know that
in order to use slices. In point of fact I think that if
tomorrow they changed the default to something different
not a single program would break.

>> But you can't do
>> 
>>   for key in tree.iterkeys('a',)
>> 
>> or more regrettably, you can't do:
>> 
>>   for key in tree.iterkeys(,'b')
>
> If your datatype defines iterkeys to accept start and end arguments then 
> you can do:
>
>    for key in tree.iterkeys('a',None)
>    for key in tree.iterkeys(None,'b')
>
> which is directly equivalent to the slices, or you can do:
>
>    for key in tree.iterkeys(start='a')
>    for key in tree.iterkeys(stop='b')
>
> which is more explicit.

Yes we could do all that. The question remains why we should burden
the user with all this extra information he has to know now in order
to use this method, while there is a clear notation he can use
without all this.

The user doesn't has to type:

  lst[5:None] or lst[None:7],

Neither has he to type something like
 
  lst[start=5] or lst[stop=7]


There are circumstances when the user needs to provide slice
information to a function. Why not allow him to use the
same notation as he can use in subscribtion. What reason
is there to limit a specific notation for a value to
specific circumstances. To me this looks as arbitrary
as would bracket notation not be allowed as an argument
but that you would be obligated to use list((a,b,...)) in
calls instead of [a,b,...]

It wouldn't prevent you to do anything from what you can
do now with python, it would only make a number of things
unnecesary cumbersome.

So yes, my proposal will not allow you to do anything you
can;t already do now. It would just allow you to do a number
of things in a less cumbersome way.

>> I also think that other functions could benefit. For instance suppose
>> you want to iterate over every second element in a list. Sure you
>> can use an extended slice or use some kind of while. But why not
>> extend enumerate to include an optional slice parameter, so you could
>> do it as follows:
>> 
>>   for el in enumerate(lst,::2)
>
> 'Why not'? Because it makes for a more complicated interface for something 
> you can already do quite easily.

Do you think so? This IMO should provide (0,lst[0]), (2,lst[2]),
(4,lst[4]) ...

I haven't found a way to do this easily. Except for something like:

start = 0:
while start < len(lst):
  yield start, lst[start]
  start += 2

But if you accept this, then there was no need for enumerate in the
first place. So eager to learn something new, how do you do this
quite easily?

-- 
Antoon Pardon





More information about the Python-list mailing list