generator expressions: performance anomaly?

[Jeremy Bowers]

On Tue, 18 Jan 2005 14:05:15 +0000, Antoon Pardon wrote:
> I don't see how generating byte code for a = 9; when seeing the
> expression a = 3 + 6, would be a problem for non-functional
> languages.

To answer nearly every post you've made to this thread, "because Python
doesn't have the resources to program to special cases".

And as is often the case in this sort of discussion, sure, adding this
might be only a little work, but there's thousands of enhancements of the
same general work level and performance gain. So remember you're not just
espousing this particular enhancement, you're implicitly arguing for the
entire class (because there is nothing to discriminate in the argument
"this is fairly easy" between this particular feature on your mind today
and the other thousands of such features).

To address your point more specifically, you can do this subexpression
elimination to the extent that your expression is a purely functional one.
"a = 3 + 6", while written in an imperative language and setting a
variable in an imperative manner, has a "functional subexpression" "3 +
6", that has no side-effects, etc., so the compiler could reduce it if it
knew how. (In Python, that's a function call, but since you can't change
__add__ on ints, you could do this, although there's still some special
casing you're doing that will ripple unpleasantly through the code.) But
as soon as you call any sort of method or function, you're done.

Ultimately, the use is fairly limited; I can't imagine the execution time
saved would reach the time of implementation for weeks after a release,
even aggregating across all Python use in the world, and "real time
gained" (i.e., time useful to a human) would probably never add up to the
implementation time. So why bother? That's a horrid trade off when there
are so many other real gains to be had.