Antoon Pardon <[EMAIL PROTECTED]> 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. > 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. Second: you overload the meaning of slicing and the slice operator and so on. range is perfectly integrated and the right tool for the job. There's no need to introduce new syntax to iterate over a range of integers. > 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? -- Lawrence - http://www.oluyede.org/blog "Nothing is more dangerous than an idea if it's the only one you have" - E. A. Chartier -- http://mail.python.org/mailman/listinfo/python-list
