Tuple slices

[George Sakkis]

"Terry Reedy" <tjreedy at udel.edu> wrote in message news:mailman.1308.1106688018.22381.python-
>
> Unless you are GvR or Tim Peters,

Actually I am the OP. I posted my previous mail from Google groups, which for some reason put my
email instead of my name; it should be ok now.

> 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.

Thanks for the info; a citation that supports your claim that the in-memory copy is part of the
*specification* of a tuple slice -- and not a choice that is subject to the implementation -- would
be useful. Note that I'm talking only about slices of *tuples* (or any immutable sequence for that
matter) here, not all slices. As for the "pythonic", I mentioned it as a loosely speaking synonym to
"simpler" or "more intuitive"; I apologize if this term has religious connotations in cl.py.

> 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.

I fail to understand where does your strongly negative tone come from; certainly not from my posts.
I asked a simple question and I was expecting a simple answer, not defending myself from a
hypothetical shortsighted suggestion to Guido. Thankfully I got one (and only so far) good reason
for the current implementation from Fredrik Lundh, namely the reference to the original object.

> 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

Honestly, I can't imagine a case where supplying these three associated data packaged is *less*
convenient than spelling them out explicitly.

> 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.

This is not the point; that function was just the motivation for questioning the current tuple slice
implementation. I wouldn't start this thread in the first place if I didn't have the impression that
tuple views would be beneficial for many (most?) cases.

> It partly depends on what he wishes to optimize, which I asked about, but
> have not yet seen an answer about.

Are you sure you read the whole thread ? I replied explicitly on this to Jeff Shannon:

"You're probably right about the allocation time, but my main concern is the memory required for
each slice, which can be O(n) wrt the length of the whole tuple. I would like this to be constant
(at least if there was a way around to the problem of deleting the underlying sequence)."

> So I suggested the simplest approach that would work.  And that, to me, *is* pythonic!

Simplest to whom ? The user or the py-dev guy that implements tuples ? It sounds as if you have the
second in mind.

> Terry J. Reedy
>

George