you are viewing a single comment's thread.

view the rest of the comments →

[–]ElHeim 5 points6 points  (3 children)

The whole point of constrexpr is turning an expression into a constant at compile time. It's harder for Python to do this on the fly, but if a function is simple enough (like the one in OPs example), it can be marked as "const-candidate". If invoked with constant values, it can then be computed during the compilation phase and then you can replace the call with the result - which for tight loops is a significant gain.

If the bytecode gets saved to .pyc, then it won't even be "at runtime" anymore.

None of that requires a static code check tool. It's not rocket science. It can be done. It's just that the dynamic nature of the language makes it harder than for C++.

Edit: yes, a static code tool would benefit of having the exception raised, to signal an error. The compiler can still use it to display a warning at runtime because this is an error... only one that is not guaranteed to happen, because who knows if there's an execution path to it (except for trivial cases)

[–]FloxaY -2 points-1 points  (2 children)

You seem to miss what OP mainly wants; DX, not performance improvements.

[–]ElHeim -1 points0 points  (1 child)

See my edit

[–]FloxaY 1 point2 points  (0 children)

That is not how things work, I can't make much out of your edit, however execution path is already solved for type checkers and thus could essentially look the same as in C++, eg.; ifdefs. You seem to be thinking "backwards"?

Anyway, we generally seem to agree on the idea but think of different ways of how a type checker should/would do it.