dict = no ordered keys = no slicing

[Nick Vatamaniuc]

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

Antoon,

First of all there is a distinction between ordered and un-ordered data
types. You can only slice ordered data types. Lists and tuples are
ordered while the keyset (note the _set_ part) of a dictionary is a set
- it is un-ordered and consists of unique elements, the keys.

Besides, I don't really understand what you mean by saying "a tree acts
like a dictionary"? You don't really iterate over the dictionary
because the keys are not in order! Remeber that. The confusing part is
that ks=dic.keys() will return a list so that makes you think ks[0] is
somehow first for some reason, but it shouldn't be.

You see, dictionaries were there in Python before sets(), that is why
when sets are supposed to be used a dictionary or list is used. keys()
is one of these example. Hopefully this will change in P3K so that the
key_set_ of a dictionary is a set() so people don't get confused.

As far as the tree goes, I still don't see how you would apply the
slice operator to the tree. You can traverse the tree in-order,
pre-order or post-order so how does slicing fit in there.

Hope this helps,
Nick Vatamaniuc


Antoon Pardon wrote:
> 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