4 ms·
This is where Python being dynamic makes things like this hard. You have no idea what range does, as that name may point to any user defined object by the time
by scbrg 5y ago
This is where Python being dynamic makes things like this hard. You have no idea what range does, as that name may point to any user defined object by the time the code is being executed.
So no, I don't think it can "optimize both loops away".
Come to think of it, you don't particularly know what sum = sum + i is doing either. There could be an __radd__ implementation in whatever your custom range spits out that indexes the WWW, renders a Mandelbrot or whatever.
And yes, of course overloading range and __radd__ that way would also be considered stupid, but if the loops were optimized away, it wouldn't be a drop in replacement for Python.
- nextlevelwizard 5y agothe compiler can literally see that the `list` variable is only used to generate the `sum` variable and that the `sum` is never used. Since the `sum` is never accessed by anyone it can be optimized away and now since the only accesser of `list` is gone it too can be optimized away. Thus both loops most certainly CAN and SHOULD be removed from the final compiled code. Only reason Python can't do it is because it is not compiled, so it has to actually run through the code at runtime and see what happens. This is basic static analysis and any other compiler for any other language would do this. This is literally why we have keywords like `volatile` in compiled languages. I don't understand your first argument at all. Why wouldn't the compiler know what the standard `range()` function does? The second one only makes sense since we aren't type hinting, however that too could be reversed by analyzing the code. If we can't trust the functions in standard library then what is the benefit of compiling the code?
- scbrg 5y ago> I don't understand your first argument at all. Why wouldn't the compiler know what the standard `range()` function does? The second one only makes sense since we aren't type hinting, however that too could be reversed by analyzing the code. I'm sure it knows what the standard range() function does. It just doesn't know that that's the standard range function you use when the code is being run. Any Python program is also a module. Any module can be imported. Any imported module's global namespace is unknown at the time you write the program. Imagine I have your code, above, in a module called nextlevelwizard, and I write my own little progam as this: import builtins def myrange(n): cur = 0 while cur < n: print(cur) yield cur cur += 1 builtins.range = myrange import nextlevelwizard Now, suddenly, your loop has a side effect. Side effects cannot be "optimized away" - the whole point of programs are generally to produce some sort of side effect! This is a silly example, of course, but the dynamic nature of Python means that it really is very hard to skip steps you assume are irrelevant.
- nextlevelwizard 5y agoExpect the compiler should import whatever module you are using and analyze that module's code just like in any compiled language. Even in the example you gave it could replace the loop with a bunch of print calls since the result (yields) do nothing. Compilers are hard.