Tuple slices

[Terry Reedy]

<gsakkis at rutgers.edu> wrote in message 
news:1106666051.334641.70740 at z14g2000cwz.googlegroups.com...
>
> Terry Reedy wrote:
>> In other words, if you don't really want slices copied out of the 
>> sequence,
>> then don't slice!  Just use 2 ints to indicate the working region or 
>> view.
>> Both this and using a nested function with additional params are 
>> standard
>> techniques.  This also works when the seq is mutable and you want 
>> changes
>> to the 'slice' to change the original, as in quicksort.
>
> I would say these are standard *C/C++* techniques; slicing simplifies
> things and thus seems more 'pythonic' to me.

Unless you are GvR or Tim Peters, throwing 'pythonic' at me doesn't cut it 
with me, especially when you use it so shallowly.  The current Pythonic 
meaning of 'slice', as defined by GvR and implemented in core Python 
sequence objects and documented in the reference manuals and reiterated by 
GvR on PyDev in just the last day, is to make an independent in-memory 
#copy# of the indicated part of a sequence.  Both aspects are intentional 
and desired features, not accidents.

Yes, slicing, even in the Pythonic sense, may well simplify the OP's 
algorithm (of which he gave almost no detail), but the whole point of this 
thread is that he does not want to do that (make copy slices).  While he 
might shortsightedly think that he wants Guido to redefine slice and 
replace the current implementation of tuple with a more spacious, possibly 
slower one that would allow that definition, that will not solve his 
current problem, if indeed he has one.

As George Sakkis the OP noted, the essential data constituting a contiguous 
section view are the underlying sequence and two position markers.  Whether 
one works with these directly or packages them into a tuple or user class 
instance is a matter of relative conveniences.  As it turns out, I was 
thinking about the design choices involved in a generic sequence view class 
just the morning before reading the original post.  But I have no idea 
whether GS's foo function would justify the added overhead of such a thing. 
It partly depends on what he wishes to optimize, which I asked about, but 
have not yet seen an answer about.  So I suggested the simplest approach 
that would work.  And that, to me, *is* pythonic!

Terry J. Reedy