Tuple slices

[Jeff Shannon]

[My newsreader crapped out on sending this; apologies if it appears 
twice.]

George Sakkis wrote:

> "Terry Reedy" <tjreedy at udel.edu> wrote in message
> news:mailman.1226.1106605134.22381.python-list at python.org...
> 
>>Aside from the problem of not being able to delete the underlying object,
>>the view object for a tuple would have to be a new type of object with a
>>new set of methods.
> 
> It *could*, but it doesn't have to. One can represent a view as essentially an object with a pointer
> to a memory buffer and a (start,stop,step) triple. Then a "real tuple" is just a "view" with the
> triple being (0, len(sequence), 1).

Except that that's not how Python tuples *are* constructed, and it'd
be a pretty big deal to redo the architecture of all tuples to support
this relatively special case.

Even if this re-architecting were done, you're still constructing a
new object -- the difference is that you're creating this
(start,stop,step) triple instead of duplicating a set of PyObject*
pointers, and then doing math based on those values instead of
straightforward pointer access.  I'm not at all convinced that this
really saves you a significant amount for tuple slices (really, you're
still constructing a new tuple anyhow, aren't you?), and it's going to
cost a bit in both execution time and complexity in the common case
(accessing tuples without slicing).  If there's a big cost in object
construction, it's probably going to be the memory allocation, and for
a reasonable tuple the size of the memory required is not going to
significantly affect the allocation time.

Jeff Shannon
Technician/Programmer
Credit International