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 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?
Jeff Shannon Technician/Programmer Credit International
-- http://mail.python.org/mailman/listinfo/python-list
