On Wed, 2 Dec 2020 18:33:49 +1100 Chris Angelico email@example.com wrote:
So do you think that the strict mode can help people to create a JIT for Python?
That's my aspiration for the strict mode, yes. (I provide "full disclosure" on that fact.) Beyond that, strict mode, is well, strict. So, it may be interesting to people who want more "strictness" in Python. For example, some time ago, "type annotations" were introduced, and quite many people (though not everyone of course) aspire to make their programs more strict using them. The "strict mode" proposed here is similar, but explores different dimension of strictness.
Type annotations don't add any strictness. They just give information so that an external tool can choose to provide information to the coder.
Teh "strict mode" proposed here can be seen as such an external tool too. (It can be internal tool too.)
Python can't change its execution plans based on type
CPython can't, other Pythons can. Mypyc is a well-known Python which changes its execution plans based on type annotations.
So, the culprit is the same: people continue to think Python == (current) CPython. We now seem to get to the point that most advanced people say "no, no, we understand the difference", but they continue to *think* that. They try to "size up" a change to their *CPython* experiences (slow-loading numpy, blah-blah), even though have been warned that way won't lead them anywhere. (They'll make a big circle and arrive to the conclusion "I can't use that with CPython right away", but that was the (implied) content of the initial warning).
So again, you should not compare the "strict mode" with CPython. You should compare it with Mypy, Mypyc, Shedskin, Cython, pyflakes (nags you about things, and strict mode nags you too), etc.