On Wed, Dec 2, 2020 at 6:20 PM Paul Sokolovsky firstname.lastname@example.org wrote:
On Wed, 2 Dec 2020 00:10:41 +0100 Marco Sulla Marco.Sulla.Python@gmail.com wrote:
On Tue, 1 Dec 2020 at 23:49, Paul Sokolovsky email@example.com wrote:
On Wed, 2 Dec 2020 09:16:56 +1100 Chris Angelico firstname.lastname@example.org wrote:
If the restricted execution model is incompatible with most Python scripts, why would anyone bother to use it?
E.g. because someone who would want to experiment with JIT, would need to apply similar restrictions anyway.
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. Python can't change its execution plans based on type annotations, because they have no actual runtime meaning; and the corollary of that is that type annotations are fairly safe. Annotating a function won't suddenly break it (assuming the annotation is syntactically valid).
If constness can be used to actually change behaviour, then it really does have to restrict the language, and that's quite a different beast.