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

> may go in the other direction) at a cost of complexity and speed.  You
> have greater dependence of internal objects on each other, you can't
> get rid of the original tuple while any slice views of it exist, you
> gain nothing in the way of syntax/usage simplicity...  so what's the
> point?
>
> To my mind, one of the best things about Python is that (for the most
> part) I don't have to worry about actual memory layout of objects.  I
> don't *care* how tuples are implemented, they just work.  It seems to
> me that you're saying that they work perfectly fine as-is, but that
> you have a problem with the implementation that the language tries its
> best to let you not care about.  Is this purely abstract philosophy?

No, it's called "scalability", and it's not purely abstract philosophy AFAIK. I 
fully agree that for
the most part you don't have to care about it, and I'm grateful that python 
does all its magic
trasparently. However if you do care about it, and at the same time you are 
unwilling to sacrifice
the elegance of slices, the current implementation is not ideal.

> Jeff Shannon
> Technician/Programmer
> Credit International

George


-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to