On 06/30/2013 06:32 AM, Nick Coghlan wrote:
If we removed that one difference, it would be even simpler. I don't think the difference buys us anything, and the cost of eliminating it is a relatively simple patch with minimal performance impact. (As a minor side benefit, that would also mean you could use the StopIteration hack in comps, but I still don't think we'd want to recommend doing that.) An interesting rationale, especially along with your reply to Ron about how much simpler that approach is than attempting to optimize
On 30 June 2013 17:26, Andrew Barnert<abarnert@yahoo.com> wrote: list(genexp), while still yielding a semantically equivalent end result.
It still raises my "behavioural change without adequate justification" hackles, but I'm only -0 now, whereas I was definitely -1 earlier. It's definitely a much smaller change than the scoping one we introduced in the Python 3 migration, which had the dual motivation of moving the iteration variable into a private scope, and better aligning the other semantics of "[x for x in y]" vs "list(x for x in y)".
Yes, that was also my point. It's the same as in-lineing the generator parts into the iterator that is driving it. We don't need to do that because we already have an optimised version of that. It just needs to catch the StopIteration to be the same. I'm +1 for this. I still would like to see actual time comparisons, and have it pass pythons test suit. I don't think there would be any issues with either of those. I think that it's not uncommon for people to think this is how list comps work. And I think it is surprising for them that the StopIteration isn't caught. Cheers, Ron