[ic_fly2]

If in the end we can just have .spy on some files that have performance critical functions in them and the rest is just normal python, this could be down right amazing.

We recently swapped out mypyc optimised module for a rust implementation to get a 2-6x speed up, and not having to do that would be great.

[oofbey]

+1 this.

Also, when I read about the language features which make Python intrinsically slow, generally I think "I never use that." e.g. operator overloading meaning you need to do all these pointer dereferences just to add two numbers together. Yes, I get that pytorch and numpy rely critically on these. But it makes me wonder...

Could you disable these language features on a module-by-module basis? That is, declare "in this sub-tree of the source code, there shalt be no monkey-patching, and no operator overloading" and therefore the compiler can do a better job. If anybody tries to do the disallowed stuff, then it's a RuntimeError. Would that work?

[codethief]

It probably would but it'd likely not be trivial. Because how do you recognize monkey-patching in a dynamically typed language? I can think of many edge cases here.

That being said, you might be interested in https://docs.python.org/3/reference/datamodel.html#slots

[adsharma]

See my other comment in the thread. I would argue that anything that uses arcane dynamic stuff in python should be renamed to .dpy and the vast majority of the commonly used constructs retain .py

The issue in HN threads like this is that everyone is out to promote their own favorite language or their favorite python framework that uses dynamic stuff. The majoritarian and hacker-ethos of python don't always line up.

Like Chris Lattner was saying on a recent podcast, he wrote much of Swift at home on nights/weekends over 18 months. We need someone like that do this for spy.