EuroPython 2006 and Py3.0

[Lawrence Oluyede]

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"

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

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

Yep but generators are better to iterate. list(range_object) is less
common than for i in range_object AFAIK

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

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


-- 
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier