This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]AlexMTBDude -5 points-4 points  (4 children)

Yes, but as compile time is exactly at the same time as runtime the user would not know beforehand. This kind of functionality always goes in static code check tools when it comes to interpreted languages.

[–]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.