slice notation as values?

[Antoon Pardon]

Now slices are objects in python, I was wondering if slice
notation will be usable outside subscribtion in the future.

Will it ever be possible to write things like:

a = 4:9
for key, value in tree.items('alf a.': 'beta.'):

--
Antoon Pardon

[Duncan Booth]

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']

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(N one,'b')

which is directly equivalent to the slices, or you can do:

for key in tree.iterkeys(s tart='a')
for key in tree.iterkeys(s top='b')

which is more explicit.
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.

[Antoon Pardon]

On 2005-12-10, Steven Bethard <st************ @gmail.com> wrote:

Antoon Pardon wrote:

So lets agree that tree['a':'b'] would produce a subtree. Then
I still would prefer the possibility to do something like:

for key in tree.iterkeys(' a':'b')

Instead of having to write

for key in tree['a':'b'].iterkeys()

Sure I can now do it like this:

for key in tree.iterkeys(' a','b')

But the way default arguments work, prevents you from having
this work in an analague way as a slice.

How so? Can't you just pass the *args to the slice contstructor? E.g.::

def iterkeys(self, *args):
keyslice = slice(*args)
...

Then you can use the slice object just as you would have otherwise.

This doesn't work for a number of reasons,

1)

slice() Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice expected at least 1 arguments, got 0
2) It doens't give a clear way to indicate the following
kind of slice: tree.iterkeys(' a':). Because of the
follwing:
slice('a')

slice(None, 'a', None)

which would be equivallent to tree.iterkeys(: 'a')

--
Antoon Pardon

[Antoon Pardon]

On 2005-12-10, Duncan Booth <du**********@i nvalid.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(N one,'b')

which is directly equivalent to the slices, or you can do:

for key in tree.iterkeys(s tart='a')
for key in tree.iterkeys(s top='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

[Devan L]

Antoon Pardon wrote:

On 2005-12-10, Duncan Booth <du**********@i nvalid.invalid> wrote:

[snip]

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?

lst = ['ham','eggs','b acon','spam','f oo','bar','baz']
list(enumerate( lst))[::2]

[(0, 'ham'), (2, 'bacon'), (4, 'foo'), (6, 'baz')]

No changes to the language necessary.

[Brian Beck]

Antoon Pardon wrote:

Will it ever be possible to write things like:

a = 4:9

I made a silly recipe to do something like this a while ago, not that
I'd recommend using it. But I also think it wouldn't be too far-fetched
to allow slice creation using a syntax like the above...

http://aspn.activestate.com/ASPN/Coo.../Recipe/415500

--
Brian Beck
Adventurer of the First Order

[Steven Bethard]

Antoon Pardon wrote:

On 2005-12-10, Steven Bethard <st************ @gmail.com> wrote:

Antoon Pardon wrote:

So lets agree that tree['a':'b'] would produce a subtree. Then
I still would prefer the possibility to do something like:

for key in tree.iterkeys(' a':'b')

Instead of having to write

for key in tree['a':'b'].iterkeys()

Sure I can now do it like this:

for key in tree.iterkeys(' a','b')

But the way default arguments work, prevents you from having
this work in an analague way as a slice.
How so? Can't you just pass the *args to the slice contstructor? E.g.::

def iterkeys(self, *args):
keyslice = slice(*args)
...

Then you can use the slice object just as you would have otherwise.

This doesn't work for a number of reasons,

1)

slice()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice expected at least 1 arguments, got 0

I wasn't sure whether or not the slice argument was optional.
Apparently it's intended to be, so you have to make one special case:

def iterkeys(self, *args):
keyslice = args and slice(*args) or slice(None, None, None)
2) It doens't give a clear way to indicate the following
kind of slice: tree.iterkeys(' a':). Because of the
follwing:
slice('a' )

slice(None, 'a', None)

which would be equivallent to tree.iterkeys(: 'a')

Well, it certainly gives a way to indicate it:

tree.iterkeys(N one, 'a')

Whether or not it's a "clear" way is too subjective of a topic for me to
get into. That's best left to Guido[1]. My point is that it *does*
work, and covers (or can be slightly altered to cover) all the
functionality you want. That doesn't mean you have to like the API for
it, of course.

STeVe

[1] By which I mean that you should submit a PEP on the idea, and let
Guido decide which way is prettier. Just be sure to give all the
equivalent examples - i.e. calling the slice constructor with the
appropriate arguments.

[Bengt Richter]

On 10 Dec 2005 12:07:12 -0800, "Devan L" <de****@gmail.c om> wrote:

Antoon Pardon wrote:

On 2005-12-10, Duncan Booth <du**********@i nvalid.invalid> wrote:

[snip]

>> 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?

lst = ['ham','eggs','b acon','spam','f oo','bar','baz']
list(enumerate( lst))[::2][(0, 'ham'), (2, 'bacon'), (4, 'foo'), (6, 'baz')]

No changes to the language necessary.

Or, without creating the full list intermediately,

lst = ['ham','eggs','b acon','spam','f oo','bar','baz']
import itertools
list(itertools. islice(enumerat e(lst), 0, None, 2))

[(0, 'ham'), (2, 'bacon'), (4, 'foo'), (6, 'baz')]

Regards,
Bengt Richter

[Duncan Booth]

Brian Beck wrote:

Antoon Pardon wrote:

Will it ever be possible to write things like:

a = 4:9

I made a silly recipe to do something like this a while ago, not that
I'd recommend using it. But I also think it wouldn't be too far-fetched
to allow slice creation using a syntax like the above...

http://aspn.activestate.com/ASPN/Coo.../Recipe/415500

Another possibility would be to make the slice type itself sliceable, then
you could write things like:

a = slice[4:9]
a slice(4, 9, None)

Sample implementation:
class MetaSlice(objec t): def __getitem__(cls , item):
return item
def __init__(self, *args, **kw):
return super(MetaSlice ,self).__init__ (self, *args, **kw)

class Slice(slice): __metaclass__=M etaSlice

Slice[2:3] slice(2, 3, None) Slice[:3] slice(None, 3, None) Slice[:3:-1]

slice(None, 3, -1)

[Antoon Pardon]

Op 2005-12-10, Devan L schreef <de****@gmail.c om>:

Antoon Pardon wrote:

On 2005-12-10, Duncan Booth <du**********@i nvalid.invalid> wrote:

[snip]

>> 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?

lst = ['ham','eggs','b acon','spam','f oo','bar','baz']
list(enumerate( lst))[::2]

[(0, 'ham'), (2, 'bacon'), (4, 'foo'), (6, 'baz')]

It is not about what is needed, but about convenience.

Now let me see, in order to just iterate over the even elements
of a list with the index of the element, you turned an iterator
into a list, which you use to create an other list which you
will finaly iterate over.

If this is the proposed answer, I wonder why iterators were introduced
in the first place. I thought iterator were went to avoid the need
to construct and copy list when all you want is iterate and when
I ask how to get a specific iterator you come with a construct that
makes rather heavily use of list constructions.

--
Antoon Pardon

[Antoon Pardon]

Op 2005-12-10, Brian Beck schreef <ex****@gmail.c om>:

Antoon Pardon wrote:

Will it ever be possible to write things like:

a = 4:9

I made a silly recipe to do something like this a while ago, not that
I'd recommend using it. But I also think it wouldn't be too far-fetched
to allow slice creation using a syntax like the above...

The point is that the syntax "4:9" is already used for slice creation.

The python grammer is essentally saying that something like 4:9 is a
literal, just like strings and numbers, but that this specific literal
can only be used in a subscription.

Look at the following:

import dis
def foo(): .... lst[[2,3,5]]
.... lst[8:13:21]
.... dis.dis(foo)

2 0 LOAD_GLOBAL 0 (lst)
3 LOAD_CONST 1 (2)
6 LOAD_CONST 2 (3)
9 LOAD_CONST 3 (5)
12 BUILD_LIST 3
15 BINARY_SUBSCR
16 POP_TOP

3 17 LOAD_GLOBAL 0 (lst)
20 LOAD_CONST 4 (8)
23 LOAD_CONST 5 (13)
26 LOAD_CONST 6 (21)
29 BUILD_SLICE 3
32 BINARY_SUBSCR
33 POP_TOP
34 LOAD_CONST 0 (None)
37 RETURN_VALUE

So you see that the slice is treated in an similar way
as the list. There is no reason why this shouldn't work
in case we want a slice in an assignment or a function
call.

--
Antoon Pardon