On 25.04.2018 01:19, Steven D'Aprano wrote:
Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
sometimes g is better. [...]
We were talking about the real-world code snippet of Tim (as a
justification of := ) and alternative rewritings of it without resorting
to new syntax.
Not about "sometimes", or in some toy examples, or code without unknown
life-time and intention (interactive, library, etc).
You might know that, but how does somebody reading the code know
which functions are pure and which are not? How does the compiler know?
There are invisible optimizations in CPython already.
And for the most obvious examples, humans don't need to know. It's like
wondering if constant folding really works.
It's the same with all optimizations: if it works, it's fine. If it
cannot be made working, the original code still works and you can
optimize by hand anyway.
The two obvious ways: the compiler might have a predefined list of pure
functions OR the code tells him with an annotation of any sort.
Both ways work, the latter somehow feels cleaner.
It's easy to say that you recognise gcd as a pure function. How about
len(document.chapter[this_chapter].pages()), is that a pure function?
What exactly do you want me to answer? An algorithm? A trained neural
network?
Usually, one starts with the low-hanging fruits and extends if possible
and needed.
So that would be way out of scope.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
