Hello,
On Tue, 1 Dec 2020 19:09:28 +0000
David Mertz
There exist TWO highly successful, widely used, JIT compilers for Python. PyPy and Numba. Neither one of them would have any use whatsoever for this constantness.
Of course not. What PyPy needed were European Commission grants, nothing else. Numba needed a lot of corporate backing for sure too, but they also needed LLVM bindings. So they picked some guy's module. Then they threw it away, because it was hard to maintain, and made their own. While LLVM has always shipped Python bindings. That's absolutely normal, but shows there's a lot of "random betting" happens even in "highly successful" projects. But most importantly, I'm not interested in survivorship bias. I'm not much interested to know how to write million-dollar JIT projects, because heck, that's known for decades. I'm interested to know how to NOT write "million-dollar" JIT projects, and why Unladen Swallow, Pyston failed. I'm also interested to know how to write JIT projects which do NOT cost millions of dollars. All that is quite an unusual hobby, you bet.
Or if you believe otherwise, get a developer of one of those to comment so. JIT'd Python simply is not slow, even compared to compiled languages.
Yeah! It's just don't work for stuff you need in a way you need, and too bloated, so when you want to fix it, you can't.
Searching for maybe-possibly-someday optimizations while ignoring the actual speed paths, is silly.
Exactly interested in low-hanging optimizations. Much less interested in approaches like "we'll feed in some random crap, and LLVM will take care of it". So, hopefully, the motivation is clear - I'm doing this stuff, because it's so obvious thing to do, and the guys who got the same idea in 2001 or so, didn't seem to have left tangible artifacts beyond deadlocked PEPs.
But I'll be moderate and only vote -100, 10x less negative than Paul Moore and Chris Angelico :-).
[] -- Best regards, Paul mailto:pmiscml@gmail.com