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. -- http://mail.python.org/mailman/listinfo/python-list
