On Tue, 25 Jan 2005 19:25:55 -0500, "George Sakkis" <[EMAIL PROTECTED]> wrote:
>"Jeff Shannon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> George Sakkis wrote: >> >> > An iterator is perfectly ok if all you want is to iterate over the >> > elements of a view, but as you noted, iterators are less flexible than >> > the underlying sequence. The view should be (or at least appear) >> > identical in functionality (i.e. public methods) with its underlying >> > sequence. >> >> So, what problem is it, exactly, that you think you'd solve by making >> tuple slices a view rather than a copy? >> >> As I see it, you get the *possibility* of saving a few bytes (which > >It all comes down on what you mean by "a few bytes". Since many (most?) slices >are linear wrt to the >original sequence's length, it is not hard to think of algorithms that involve >the creation of >*many* slices (e.g. most recursive divide-and-conquer algorithms). >Implementing these using slices >simply does not scale as the input sequence gets larger. Of course, you can >always use the standard >C/C++ approach and pass the original sequence along with the (start,stop,step) >indices of the slice, >as Terry Reedy mentioned, but then you lose in expressiveness. I didn't see the leadup to this, but what is the problem with just subclassing tuple to give you the views you want? Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
