<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 -- http://mail.python.org/mailman/listinfo/python-list
