I think sadly a lot of Python in the wild relies heavily, somewhere, on the crazy unoptimisable stuff. For example pytest monkey patches everything everywhere all the time.
You could make this clean break and call it Python 4 but frankly I fear it won't be Python anymore.
As a person who has spent a lot of time with pytest, I'm ready for testing framework that doesn't do any of that non-obvious stuff.
Generally use unittest as much as I can these days, so much less _wierd_ about how it does things. Like jeeze pytest, do you _really_ need to stress test every obscure language feature? Your job is to call tests.
loading story #47430522
If you do that you then have a less productive language for many use cases IMHO.
All the dynamism from Python should stay where it is.
Just JIT and remember a type maybe, but do not force a type from a type hint or such things.
As a minimum, I would say not relying on that is the correct thing. You could exploit it, but not force it to change the semantics.
loading story #47430531
Perl 6 showed what happens when you do something like that.
Allowing metaprogramming at module import (or another defined phase) would cover most monkey patching use cases. From __future__ import python4 would allow developers to declare their code optimisable.