[Raymond Hettinger] > > It is darned inconvenient to get an iterator when you really > > need a list, when you want to slice the result, when you want to see a > > few elements through repr(), and when you need to loop over the > > contents more than once.
[George Sakkis] > Similar arguments can be given for dict comprehensions as well. You'll find that "lever" arguments carry little weight in Python language design (well, you did X in place Y so now you have to do it everywhere even if place Z lacks compelling use cases). For each variant, the balance is different. Yes, of course, list comprehensions have pros and cons similar to set comprehensions, dict comps, etc. However, there are marked differences in frequency of use cases, desirability of having an expanded form, implementation issues, varying degrees of convenience, etc. The utility and generality of genexps raises the bar quite high for these other forms. They would need to be darned frequent and have a superb performance advantage. Take it from the set() and deque() guy, we need set, dict, and deque comprehensions like we need a hole in the head. The constructor with a genexp does the trick just fine. Why the balance tips the other way for list comps is both subjective and subtle. I don't expect to convince you by a newsgroup post. Rather, I can communicate how one of the core developers perceives the issue. IMHO, the current design strikes an optimal balance. 'nuff said, Raymond -- http://mail.python.org/mailman/listinfo/python-list
