On 2006-07-14, Lawrence Oluyede <[EMAIL PROTECTED]> wrote:
> 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.
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
--
http://mail.python.org/mailman/listinfo/python-list
