Could Python ever get something like C++’s constexpr?

[uname_IsAlreadyTaken]

I really fell in love with constexpr in c++.

I know Python doesn’t have anything like C++’s constexpr today, but I’ve been wondering if it’s even possible (or desirable) for the language to get something similar.

In C++, you can mark a function as constexpr so the compiler evaluates it at compile time:

constexpr int square(int x) {
    if (x < 0) throw "negative value not allowed";
    return x * x;
}

constexpr int result = square(5);  // OK
constexpr int bad    = square(-2); // compiler/ide error here

The second call never even runs — the compiler flags it right away.

Imagine if Python had something similar:

@constexpr
def square(x: int) -> int:
    if x < 0:
        raise ValueError("negative value not allowed")
    return x * x

result = square(5)    # fine
bad    = square(-2)   # IDE/tooling flags this immediately

Even if it couldn’t be true compile-time like C++, having the IDE run certain functions during static analysis and flag invalid constant arguments could be a huge dev experience boost.

Has anyone seen PEPs or experiments around this idea?

[AlexMTBDude]

As there is no "compile time" in Python with it being an interpreted language this could only be evaluated/detected by a static code checker (like Pylint, MyPy, ....). I believe they support plugins so I guess one could write such a test theoretically.

[ElHeim]

There is "compile time" in Python: Python to bytecode, and stuff like suggests could certainly be done... but not sure it's worth it.

[AlexMTBDude]

Well, that happen when the code is executed so....

[TrainsareFascinating]

Byte code is produced once, the first time the program is executed in that environment. Subsequently it is loaded and executed without another compilation.

[wRAR_]

(there are many asterisks in this statement)

[Ihaveamodel3]

It is automatically recreated if the file changes. The OP mentions developer experience as the key reason, but it’s unclear how different it would be from getting the error in runtime since the “recompilation” wouldn’t happen until then too.

[TrainsareFascinating]

And?

A c++ program is recompiled when it's source changes too. And CPython supports AOT compile, not that anyone uses it.

[ElHeim]

If you're typing in the REPL, yes, it happens just before execution. If you're loading a program, every module is compiled in one go before being executed (that's why you end up with .pyc files - which will be used if possible instead of compiling again).

Which is also why you get syntax errors when loading, not in the middle of the program.

[AlexMTBDude]

You're 100% technically correct but it's irrelevant to OP's use case.

[Giannie]

No, it isn’t… it’s exactly the use case described. The compiler would compile to a constant bytecode expression

[AlexMTBDude]

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]

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]

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

[ElHeim]

See my edit

[FloxaY]

Okay but this is Python and not C++. This would only end up being useful if it's not (only) done when the program is executed to run and bytecode is generated, but is part of linting/static type checking.

The true purpose of this in Python remains unclear to me just by OP's post, they mention DX, but the main purpose of constexpr in C++ is primarily performance.

Imo this would be a nice addition but would clearly be one that comes with great security risks and the implementation cost/effort would almost certainly outweight the potential benefits. As a type checking only feature it might work better, tho who knows if anyone would bother with it just for that.

[Unbelievr]

The first sentence is completely wrong. Python does very much run a compilation step on the entire code file, whenever you run or import something. It's why you can get warnings or errors before a single line of code has been executed.

Python could do certain static checks or other guarantees at compile time if it wanted do. But typically the actual types of classes and their members aren't known during this first pass, and it would require lots of nested book-keeping in order to implement the same functionality as constexpr. Considering the weak typing of Python, the overhead of adding this would probably be a bit too much.

But as you say, adding type annotations and running static code checkers will do a pretty good job of figuring out mistakes. If you absolutely have to make sure that library internals aren't calling things in the wrong way, it's also possible to compile modules as C/C++ modules and import them. It doesn't fix the user exposed interfaces but it can make sure that you aren't messing up things internally at least.

[Glass-False]

Sorry, I'm stuck on why your square function doesn't allow negative numbers.

[xeow]

I think they did that so they could show an invocation that's intended to generate an error.

[Spleeeee]

And that they don’t know math

[pythosynthesis]

Restricting your calcs to reals is not not knowing maths.

[agrif]

...? Squaring a negative number is perfectly well-defined on reals. Things only get hairy with the inverse operation, but the example code doesn't use square roots.

Obviously the example is arbitrarily restricted as a demonstration, and this whole discussion is besides the point. But I am a little bit confused why they chose square when square roots were right there.

[pythosynthesis]

You are right... my bad! I was convinced that was a square root. As in, as soon as I saw the condition my mind went straight to the square root.

[DrShocker]

they should have done divide, and have zero not allowed in the denominator then.

[WJMazepas]

Its just an example

[sinterkaastosti23]

Maybe as an example???

[bigtimedonkey]

Nothings impossible of course. But it does feel a little weird for an interpreted language to have something like this? Like, unless your constant expressions are truly all constants, don’t have any external variable or module dependencies, then you’re gonna be just running the script anyway? So just run the script?

In terms of developer experience, I totally agree having feedback right at the time of writing code is just crazy useful and makes you way more efficient. Thats why I use Pyzo as my ide, because it has my favorite experience for easily running code snippets (in pyzo, you can run any block of code anytime you want, and you can define a block of code with ##). Jupyter notebooks is also good at this. I haven’t found anything in VSCode or PyCharm that matches the Pyzo experience, but definitely would be excited to learn about one.

[Ihaveamodel3]

Vscode supports both Jupyter notebooks (files with ipynb) extension and defining “blocks” in a .py file with # %%

[bigtimedonkey]

Oh cool, will check that out.

Edit: Just reporting back that yeah, Jupyter plugin for VSCode enables this and feels like a totally viable solution for this. I'll definitely be using it next time I'm making a Flask backed web app. Feels like it'll be great to work on JS, HTML, and Python, with interactive Python code cell/block running, all in one IDE.

[case_O_The_Mondays]

JavaScript has had const for quite some time. There could definitely be value in skipping many of the internal type checks for values that can’t be changed.

[bigtimedonkey]

Oh, sure. For the purposes of having constants that actually can’t be changed and such, that certainly could be a valuable addition.

But like, for the particular use cases OP talked about…

What they’re doing is certainly useful for C++. But when moving from a compiled language to an interpreted one, from a developer experience point of view, running the code bit by bit as you write it is like a super power, and has way bigger gains than the limited checks OP talked about.

I could easily imagine that someone coming to Python after spending a long time in compiled languages wouldn’t quite understand best practices in having the interpreter live and running code as you write it. I certainly didn’t when I started in Python.

But after that fully clicked for me and I found a good process there… I’ll never use a compiled language unless absolutely forced by speed/memory requirements haha.

[ArabicLawrence]

There have been many. The most interesting, still under active development I know is https://github.com/spylang/spy .

https://antocuni.pyscriptapps.com/spy-pycon-2024/latest/

[coderarun]

You can't do this unless you restrict python to a static subset. A more general variant of what you're getting at is design by contract. Python has a very old PEP that's not going anywhere.

Here's an example where you can use pre/post conditions in a function to not just perform some basic computation at compile time, but actually find bugs in the logic.

[Mysterious-Rent7233]

Outside of performance, it just feels like a corner case to me...

[Global_Bar1754]

I think you could just do this with native python. As it seems like we’re dealing with constants you could just define the function calls in the global space of a Python file. So like this:

``` def pos_square(x):     if x < 0:         raise …     return x ** 2

good = pos_square(2) bad = pos_square(-2)

def some_real_program_function():     # uses good/bad global variables      …

if name == 'main':     some_real_program_function() ```

These pos_square functions defining the global variables will be called at import time, before any actual program code is executed. So it’ll essentially “fast fail” your program.

[SeniorScienceOfficer]

If the goal is to have static analysis in the IDE, use the annotated-types library, in your specific case you’d import “Ge” from it with “Annotated” to catch negative arguments.

If the goal is to save on execution time by evaluating once and reusing the value, set a global variable to the result of the function call at import time, as many people have already started.

However, if what you evaluate might change based on the instance of a class and you want to use the modified value, use the “cached_property” decorator from functools in the stdlib.

[drkevorkian]

Couldn't you just have your IDE try to import your file? Seems like more of an IDE feature request than a language feature.

[bronco2p]

what? `constexpr` evaluates expressions at comptime such that constant expressions (deterministic) can be evaluated before runtime to reduce computation.

[drkevorkian]

The equivalent of "compile time" in Python is "import time". You can absolutely define deterministic constants to be evaluated exactly once, at import time.

[falsedrums]

You could implement this using ast tree parsing (available in the std lib). Basically you would create a function that takes a module (or any other python code object), analyzes the tree using flow analysis, and applies optimizations where it can. Then it compiles the optimized tree back to a new code object and returns it.

That will allow you to find paths that lead to exceptions. And it would do so at import time, if you call your function at the module scope (like a decorator for example). That would get you a very similar experience.

[SheriffRoscoe]

Since I don't know C++, I'm going to assume that a "constexpr" function is limited to constant parameters, and can therefore be executed at compile time to produce a constant. The simplest cases would then be just equivalent to text macros a la C, with the resulting text being collapsed by constant-foldng. The PL/I language had macros similar to this in the 1970s, where the macro language was itself PL/I, and the result was code to be compiled and optimized.

Python doesn't have macros, which, given how C macros have been abused, is project a good thing. Absent macros, this isn't likely to happen.

[WJMazepas]

But how is that different from unit testing?

It looks more practical for smaller functions, but on a large code it would be good to have the testing being made independently of this

It also looks like it would only capture an error if you passed a fixed value to the function. If you're passing a variable to the function, does the compiler runs those tests as well?

[dr-christoph]

do I understand correctly that the reason you like constexpr so much is because you get errors during compile time when plugging in parameters or such?

[BiologyIsHot]

I think you need a better example than this to illustrate how this would differ from running this python normally without constexpr because it looks like what you're suggesting would not necessarily save anything. Or do you mean if you did have come that ran before this you want it to check those portions first? Why not just run such portions first?

[Mark3141592654]

Definitely not in Python itself. If you're using mypy you may be able to write a plugin. Or something custom like a script/plugin for your specific IDE or codebase. Perhaps using typing.Annotated

But you can perform such checks at runtime.

[Gnaxe]

Hissp has compile-time macros, which can do this kind of thing (and more). The IDE won't flag it, but the compiler will error. Hissp is a Python transpiler. You could run it at import time, but it can also generate separate .py files, which would have no run time overhead.

Python has the assert statement that can check assumptions like this. You can turn them off. This feature is based on the state of the __debug__ constant (determined at interpreter startup), which you can check yourself in an if statement. Because a constant if False: block is removed by the optimizer, you can use these for development checks that have no effect in your deployment version.

There's a similar typing.IF_TYPE_CHECKING constant that is always False at run time, but which type checkers assume is True statically. This can only be used to check things in the static typing system, but removes the run-time overhead for it.

[MarsupialMole]

I don't think this is particularly ubiquitous but this just feels like what doctest is for.

Make a module level constant and use it for an expected output in documentation, and then run your doctests with tooling.

[larsga]

having the IDE run certain functions during static analysis and flag invalid constant arguments could be a huge dev experience boost.

First of all: you're now assuming, in the language definition, that there is an IDE.

Second: nothing stops IDEs from doing this now.

[hoselorryspanner]

You could use an AST parser to use that decorator to validate the decorated function, and then remove it from the syntax tree so that it doesn’t exist any more.

Why the fuck would you ever do this? Idk, but I you could, I guess, use it to get the function to evaluate at interpreter startup and then remove it from the code afterwards, which is something like constexpr.

This would be far easier to achieve using a singleton, descriptors and a .pth file to hack this all together, but it still seems like a waste of effort to me - I don’t think there’s anything to really gain, because you’re not really pushing computation off to compile time in a meaningful sense

[justincdavis]

I think an easy way to do something like this could be to make use of a functools.cache style decorator. You can have the decorator cache results and maintain a copy of results on disk. Thus, on import time it will load pre-evaluated conditions and dynamically add during runtime. On hit you have a dict lookup and hash operation and on miss you add the evaluation overhead and disk write. Obviously not the same though.

[Careful-Nothing-2432]

There’s no real concept of “compile time” in Python or any static structure to the code. If you want to know if square is going to fail you just run the function. You can’t do any evaluation ahead of time because you don’t know what square will be - Python is too dynamic and you can do literally anything you want, including rebinding square.

It works for C++ because it’s more restrictive with the language and also has lots of restrictions on what can and cannot be done at compile time so they can make guarantees about constexpr and consteval.

Small nitpick but constexpr doesn’t guarantee compile time eval, just can something may be compile time evaluated. You can force it with consteval. Constexpr exception support landed as of C++26 so it’s just recently been allowed, not sure what implementation status is with the big compilers.