Hello, On Wed, 02 Dec 2020 12:36:23 +1300 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 2/12/20 6:43 am, Paul Sokolovsky wrote:
That's why I don't make such claims, and instead making a very different one: that idea with absolute certainty will remove *one* of 50 problems which keep Python slow.
But without an implementation demonstrating an actual speed improvement, you're only speculating that the problem is, in fact, keeping Python slow.
That summarizes it well, yes. Just as PEP266/PEP267/PEP280, I'm speculating on how to optimize namespace lookups. I however aspire to improve on them, providing wider, more coherent picture on how to achieve that. I also speculate in the same way as PEP509, which was accepted, and actually implemented in CPython, without any improvements on CPython speed (on its own). But it lays a framework to "maybe do it somewhere, somewhen". My proposal is very similar, but explores a different direction of changes. https://www.python.org/dev/peps/pep-0266/ https://www.python.org/dev/peps/pep-0267/ https://www.python.org/dev/peps/pep-0280/ https://www.python.org/dev/peps/pep-0509/
I'm also not convinced that the proposed solution is necessary to remove the problem. A sufficiently smart JIT could notice,
A sufficiently smart JIT is sufficiently hard to develop. As an example, a most well-known and most-used Python implementation, CPython, doesn't have any JIT at all, not only "sufficiently advanced", but even "simple". But simple would be much easier to add (to any project). And my proposal explores how to get specific advantages from even simple JIT techniques.
for example, that a particular function doesn't mutate its arguments and pass them in an optimised way, without needing any declarations.
-- Greg
[] -- Best regards, Paul mailto:pmiscml@gmail.com