Python and the need for speed

[Steve D'Aprano]

On Sat, 15 Apr 2017 10:23 am, bartc wrote:

> On 15/04/2017 00:40, Rick Johnson wrote:

>>   * `range(10)` will always produce a list of the _same_ 10
>>   integers.
> 
> You don't know if 'range' is still a range. If this has been executed
> first, then the answer will be 20:
> 
> oldrange=range
> def double(x): return oldrange(x*2)
> range=double

Correct.

It is true that *at the moment* CPython doesn't know if range has been
shadowed or redefined, but Victor Stinner is working on a project,
FATPython, which will. Or at least, FATPython can tell:

- there's no chance that range() has been redefined, so it is safe to
optimize the call to it;

- or there is a chance, in which case it is not safe to optimize.



>>   * `for i in range(10)` will aways iterate over the _same_
>>   10 integers
> 
> And range could be set to something else each time the loop is executed.

It could, but that won't effect the loop.

py> old_range = range
py> for i in range(5):
...     range = i*100
...     print(i)
...
0
1
2
3
4
py> range
400



>>   * `answer += 1` will always increment the "current integer
>>   value" by 1
> 
> I don't know if it's possible to override __iadd__ for integers so that
> +=1 does something different here.

No, Python doesn't allow the built-in types to be monkey-patched. However,
that's not the problem. The problem is that CPython doesn't know whether
answer is a built-in int or not until runtime.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.