Ian Bicking wrote: > Coming back around to the idea of implementing __getitem__ and such, I > suppose a list-like iterator wrapper could be useful. That would > consume and retain the results of the iterator lazily to satisfy the > things done to the object. That would be kind of interesting; I > implemented several such methods on the select result object in > SQLObject for that purpose, and that aspect actually works pretty well. > There's some predictability problems, though. bool(obj) would only > have to consume one item, but len(obj) would consume the entire thing, > and usually len() is a pretty innocuous function to use. > > If this was done, it would be nice if an iterator could give hints, like > a faster implementation of __len__ than the fallback behavior that only > can use .next().
BTW, I actually like the view idea better, though in some ways they are similar -- listish(iterator) is kind of like a list-like view on an iterator, like dict.keys() would be a multiset-like view of a dictionary's keys. As a generalized concepts views could be pretty neat and expansive. A downside is mistranslations of old code will lead to very hard bugs, as .keys() currently makes a copy. Though if the new objects aren't quite the same as lists -- e.g., implementing .add() instead of .append() -- then maybe that won't be so bad. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
