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

[Steve Holden]

Antoon Pardon wrote:

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.'):

Do you mean

for key, value in tree.items()['alfa.': 'beta.']:

What would this mean?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Antoon Pardon]

Op 2005-12-09, Steve Holden schreef <st***@holdenwe b.com>:

Antoon Pardon wrote:

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.'):

Do you mean

for key, value in tree.items()['alfa.': 'beta.']:

No, the slice is meant to be a parameter to the method.
It would be a more convenient way to write:

for key, value in tree.items(slic e('alfa.', 'beta.'))

--
Antoon Pardon

[Duncan Booth]

Antoon Pardon wrote:

Will it ever be possible to write things like:

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

The first of these works fine, except you need to use the correct syntax:

a = slice(4,9)
range(10)[a] [4, 5, 6, 7, 8]
The second also works fine, provide tree is a type which supports it and
you rewrite the call as tree.items(slic e('alfa','beta. ')) or perhaps
tree['alfa':'beta.'].items(). To support slicing directly on a dictionary
you could do:
class sliceable(dict) : def __getitem__(sel f, item):
if isinstance(item , slice):
return self.__class__( (k,v) for (k,v) in self.iteritems( )
if item.start <= k < item.stop)
return dict.__getitem_ _(self, item)
d = sliceable({'alp ha': 1, 'aaa': 2, 'beta': 3, 'bee': 4 })
d['alpha':'beta'] {'alpha': 1, 'bee': 4} d['alpha':'beta.'] {'alpha': 1, 'beta': 3, 'bee': 4} for key, value in d['alpha':'beta.'].items():

print key, value
alpha 1
beta 3
bee 4

It seems unlikely that this will make it into the builtin dict type, but
you never know.

[Antoon Pardon]

Op 2005-12-09, Duncan Booth schreef <du**********@i nvalid.invalid> :

Antoon Pardon wrote:

Will it ever be possible to write things like:

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

The first of these works fine, except you need to use the correct syntax:

Sure, I know that. But why a different syntax?

If we have lst = range(10), we can write

lst[slice(3,7)]

instead of

lst[3:7]

Now my impression is that should we only have the upper notation, slices
would be less usefull, because it would make using them more cumbersome.

I think that having this easy notation for slices available in more
general circumstances, would make the use of them in other situations
more easy too.

a = slice(4,9)
range(10)[a] [4, 5, 6, 7, 8]
The second also works fine, provide tree is a type which supports it and
you rewrite the call as tree.items(slic e('alfa','beta. ')) or perhaps
tree['alfa':'beta.'].items(). To support slicing directly on a dictionary
you could do:

class sliceable(dict) : def __getitem__(sel f, item):
if isinstance(item , slice):
return self.__class__( (k,v) for (k,v) in self.iteritems( )
if item.start <= k < item.stop)
return dict.__getitem_ _(self, item)
d = sliceable({'alp ha': 1, 'aaa': 2, 'beta': 3, 'bee': 4 })
d['alpha':'beta'] {'alpha': 1, 'bee': 4} d['alpha':'beta.'] {'alpha': 1, 'beta': 3, 'bee': 4} for key, value in d['alpha':'beta.'].items():

print key, value

alpha 1
beta 3
bee 4

It seems unlikely that this will make it into the builtin dict type, but
you never know.

It doesn't need to be in the buildin dict type, I just would think it
could make the interface to my own treedict type more intuitive.

In my treedict the keys are accessible in order. If you have dictionary
with strings as keys doing:

for key in tree:

will give you the keys in alfabetical order. Doing

for key in tree['a':'b']:

will give you all the keys that start with an 'a'.

Now there are a number of methods with similar results.
keys, values, items and there iter variants iterkeys,
itervalues and iteritems. These methods are 'sliceable'
too and I think the possibilty of giving such a method
a slice as parameter, with the same notation as in
a subscript, would be the clearest way for the user
to provide slice information.

If the user can write:

for key in tree['a':'b']:

Why shouldn't he be able to write:

for key, value in tree.iteritems( 'a':'b'):

--
Antoon Pardon

[Duncan Booth]

Antoon Pardon asked:

If we have lst = range(10), we can write

lst[slice(3,7)]

instead of

lst[3:7]

Now my impression is that should we only have the upper notation, slices
would be less usefull, because it would make using them more cumbersome.
Quite right, but the syntax for the slice only applies inside the square
brackets and there would be big problems making it work outside a
subscript. If you allowed a:b you get syntactic ambiguities: e.g. is this a
slice or a complete if statement:

if a:b

If you allow a slice on its own but require the square brackets still to be
there then you don't (I think) get any syntax ambiguities, but the result
looks like it should be some weird list comprehension so its just too
confusing:

myslice = [a:b]

I think the case for freestanding slices is there, but they aren't common
enough to justify special syntax.
If the user can write:

for key in tree['a':'b']:

Why shouldn't he be able to write:

for key, value in tree.iteritems( 'a':'b'):

import this

....
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
....

If the user can write

for key in tree['a':'b']:

then he can write:

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

so why add a second way to do that?

[Antoon Pardon]

Op 2005-12-09, Duncan Booth schreef <du**********@i nvalid.invalid> :

Antoon Pardon asked:

If we have lst = range(10), we can write

lst[slice(3,7)]

instead of

lst[3:7]

Now my impression is that should we only have the upper notation, slices
would be less usefull, because it would make using them more cumbersome.
Quite right, but the syntax for the slice only applies inside the square
brackets and there would be big problems making it work outside a
subscript. If you allowed a:b you get syntactic ambiguities: e.g. is this a
slice or a complete if statement:

if a:b

If you allow a slice on its own but require the square brackets still to be
there then you don't (I think) get any syntax ambiguities, but the result
looks like it should be some weird list comprehension so its just too
confusing:

myslice = [a:b]

I don't see the problem. The syntax for tuples can create syntactic
ambiguities too. Take the following statement:

f(a,b)

Does the call have two parameters or one that is a tuple? In practice
one uses parenthesis to disambigue the stament. So in the above case
it would be a complete if statement. And myslice = a:b wouldn't
cause a problem.
I think the case for freestanding slices is there, but they aren't common
enough to justify special syntax.

If the user can write:

for key in tree['a':'b']:

Why shouldn't he be able to write:

for key, value in tree.iteritems( 'a':'b'):

import this

...
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
...

If the user can write

for key in tree['a':'b']:

then he can write:

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

No he can't. tree['a':'b'] would provide a list
of keys that all start with an 'a'. Such a list
doesn't have an iteritems method. It wouldn't even
contain the information to construct items.

--
Antoon Pardon

[Duncan Booth]

Antoon Pardon wrote:

If the user can write

for key in tree['a':'b']:

then he can write:

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

No he can't. tree['a':'b'] would provide a list
of keys that all start with an 'a'. Such a list
doesn't have an iteritems method. It wouldn't even
contain the information to construct items.

Why would it produce a list?

Slicing a *list* produces a list, slicing a tuple produces a tuple, slicing
a string produces a string. I would expect slicing any other type would
also return you a new object of the same type. Thats what the code sample I
posted earlier does.

[Antoon Pardon]

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

Antoon Pardon wrote:

If the user can write

for key in tree['a':'b']:

then he can write:

for key in tree['a':'b'].iteritems():
No he can't. tree['a':'b'] would provide a list
of keys that all start with an 'a'. Such a list
doesn't have an iteritems method. It wouldn't even
contain the information to construct items.

Why would it produce a list?

Correction, it produces an iterator.
Slicing a *list* produces a list, slicing a tuple produces a tuple, slicing
a string produces a string. I would expect slicing any other type would
also return you a new object of the same type.

But iterating over a list, tuple or string, give you the elements
of a list, tuple or string one by one. Iterating over a dict
doesn't give you the elements one by one, but only the keys.

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.

So even if we agree that tree['a':'b'] should create a subtree.
Then I still would want a way to iterate over a subdomain of
the keys in the tree without creating a subtree. Yes this
would create more than one way to do the same thing. But
this is already so with builtin dicts where a number of methods
give you different ways to do things, apparantly because
according to circumstances one is more efficient than the other.

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.

With slice notation you could have the following two cases:

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

for key in tree.iterkeys(: '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')
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)

If you have an iterable, you sometime want to iterate over only a part
of it. The only way now to do so seems to be to either use a while
loop or create a second iterable over your limited domain and iterate
over the subiterable. I think it would be a an improvement if an
iterator could be constructed to just go over the subdomain within
your iterable. I also think that the most natural way to define
that subdomain would be by using slice notation.

--
Antoon Pardon

[Steven Bethard]

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.

STeVe