On 07/11/2015 12:15, Ben Finney wrote:
Bartc <b...@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
--
https://mail.python.org/mailman/listinfo/python-list
