Question about math.pi is mutable

[Bartc]

On 07/11/2015 12:15, Ben Finney wrote:
> Bartc <bc at freeuk.com> writes:
>
>> To my mind, Python allows far too much freedom in being able to change
>> anything at any time.
>
> You're welcome to that opinion. I don't see you present a reason why it
> should affect anyone else's opinion of Python, though.

Not just my option. From this 2010 paper for example ('High performance 
implementation of Python for CLI ...' by Antonio Cuni):

"As a language, Python is very hard to implement efficiently: the 
presence of highly dynamic constructs makes static analysis of programs 
extremely difficult, thus preventing ahead of time (AOT) compilers to 
generate efficient target code."

>> Yet Python has to assume 100% of the time that it could have been
>> changed. Think of the opportunities for optimising if the probability
>> was 0%.
>
> Such a pity that Python is missing all those opportunities for
> widespread adoption, by not hewing closer to your preferences.

Plenty of other people working on faster Pythons appear to have trouble 
with its being so dynamic.

(Earlier this year, I was upgrading my own language to be much more 
Python-like in its internal workings. But I gave it up because I was 
losing so many nice features that also made it easy to implement 
efficiently.

As one example of many, named constants (the 'const' feature earlier in 
the thread), were used for 'switch' statements. Without 'const', then I 
couldn't have a fast 'switch'.)

I suppose my coding style is just different from people who write 
Python. When I define a function f(), then it's always going to be 
function f and is never going to change. A call to such a function can 
therefore be streamlined.

If I ever need it to be dynamic, then I use a function pointer:

   g=f

f is still the static function, g is a now a reference to it, and is a 
little slower to call. But the /vast majority/ of function calls are 
going to be static.

-- 
Bartc