Op 2006-01-18, Tom Anderson schreef <[EMAIL PROTECTED]>:
> On Tue, 17 Jan 2006, Antoon Pardon wrote:
>
>> Op 2006-01-16, Alex Martelli schreef <[EMAIL PROTECTED]>:
>>> Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>>>
>>>> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>>>>> For finite sequences, your proposal adds nothing new to existing
>>>>> solutions like range and xrange.
>>>>
>>>> Oh come on, [5,4,..0] is much easier to read than range(5,-1,-1).
>>>
>>> But not easier than reversed(range(6)) [[the 5 in one of the two
>>> expressions in your sentence has to be an offbyone;-)]]
>>
>> Why don't we give slices more functionality and use them.
>> These are a number of ideas I had. (These are python3k ideas)
>>
>> 1) Make slices iterables. (No more need for (x)range)
>>
>> 2) Use a bottom and stop variable as default for the start and
>> stop attribute. top would be a value that is greater than
>> any other value, bottom would be a value smaller than any
>> other value.
>>
>> 3) Allow slice notation to be used anywhere a value can be
>> used.
>>
>> 4) Provide a number of extra operators on slices.
>> __neg__ (reverses the slice)
>> __and__ gives the intersection of two slices
>> __or__ gives the union of two slices
>>
>> 5) Provide sequences with a range (or slice) method.
>> This would provide an iterator that iterates over
>> the indexes of the sequences. A slice could be
>> provided
>
> +5
>
>> for i, el in enumerate(sequence):
>>
>> would become
>>
>> for i in sequence.range():
>> el = sequence[i]
>
> That one, i'm not so happy with - i quite like enumerate; it communicates
> intention very clearly. I believe enumerate is implemented with iterators,
> meaning it's potentially more efficient than your approach, too. And since
> enumerate works on iterators, which yours doesn't, you have to keep it
> anyway. Still, both would be possible, and it's a matter of taste.
>
>> But the advantage is that this would still work when someone subclasses
>> a list so that it start index is an other number but 0.
>
> It would be possible to patch enumerate to do the right thing in those
> situations - it could look for a range method on the enumerand, and if it
> found one, use it to generate the indices. Like this:
>
> def enumerate(thing):
> if (hasattr(thing, "range")):
> indices = thing.range()
> else:
> indices = itertools.count()
> return itertools.izip(indices, thing)
Fine by me. I'm not against enumerate.
>> If you only wanted every other index one could do the following
>>
>> for i in sequence.range(::2):
>>
>> which would be equivallent to
>>
>> for i in sequence.range() & (::2):
>
> Oh, that is nice. Still, you could also extend enumerate to take a range
> as an optional second parameter and do this with it. Six of one, half a
> dozen of the other, i suppose.
Yes you could probably do so and I'm not against it, I just think that
range would be a better base on which you can build enumerate and other
things than that enumenrate can be a base. e.g. __len__ could be eliminated
and len would be defined as:
def len(seq):
rng = seq.range()
return rng.stop - rng.start
--
http://mail.python.org/mailman/listinfo/python-list
