Tuple slices

[Bengt Richter]

On Tue, 25 Jan 2005 19:25:55 -0500, "George Sakkis" <gsakkis at rutgers.edu> wrote:

>"Jeff Shannon" <jeff at ccvcorp.com> wrote in message news:10vdj4s9ib19fe3 at corp.supernews.com...
>> George Sakkis wrote:
>>
>> > An iterator is perfectly ok if all you want is to iterate over the
>> > elements of a view, but as you noted, iterators are less flexible than
>> > the underlying sequence. The view should be (or at least appear)
>> > identical in functionality (i.e. public methods) with its underlying
>> > sequence.
>>
>> So, what problem is it, exactly, that you think you'd solve by making
>> tuple slices a view rather than a copy?
>>
>> As I see it, you get the *possibility* of saving a few bytes (which
>
>It all comes down on what you mean by "a few bytes". Since many (most?) slices are linear wrt to the
>original sequence's length, it is not hard to think of algorithms that involve the creation of
>*many* slices (e.g. most recursive divide-and-conquer algorithms). Implementing these using slices
>simply does not scale as the input sequence gets larger. Of course, you can always use the standard
>C/C++ approach and pass the original sequence along with the (start,stop,step) indices of the slice,
>as Terry Reedy mentioned, but then you lose in expressiveness.
I didn't see the leadup to this, but what is the problem with just subclassing tuple to
give you the views you want?


Regards,
Bengt Richter