"Terry Reedy" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
