Python is, in fact, compiled (to bytecode, not native code); while this is mostly invisible, syntax errors will cause it to fail to compile, but the circumstances described (hallucinating a function) will not, because function calls are resolved by runtime lookup, not at compile time.

I get that, and in that sense most languages are compiled, but generally speaking, I've always understood "compiled" as compiled-ahead-of-time - Python certainly doesn't do that and the official docs call it an interpreted language.

In the context we are talking about (hallucinating Polars methods), if I'm not mistaken the compilation step won't catch that, Python will actually throw the error at runtime post-compilation.

So my question still stands on what OP means by "won't compile".

> I get that, and in that sense most languages are compiled, but generally speaking, I've always understood "compiled" as compiled-ahead-of-time

Python is AOT compiled to bytecode, but if a compiled version of a module is not available when needed it will be compiled and the compiled version saved for next use. In the normal usage pattern, this is mostly invisible to the user except in first vs. subsequent run startup speed, unless you check the file system and see all the .pyc compilation artifacts.

You can do AOT compilation to bytecode outside of a compile-as-needed-then-execute cycle, but there is rarely a good reason to do so explicitly for the average user (the main use case is on package installation, but that's usually handled by package manager settings).

But, relevant to the specific issue here, (edit: calling) a hallucinated function would lead to a runtime failure not a compilation failure, since function calls aren't resolved at compile time, but by lookup by name at runtime.

(Edit: A sibling comment points out that importing a hallucinated function would cause a compilation failure, and that's a good point.)

When a module is first loaded, it's compiled to bytecode and then executed. Importing a non existing function will throw an error right away.

It's not a compilation error but it does feel like one, somewhat. It happens at more or less the same time.

Yes, that works if you do:

    from foo import nonexistent

but if you do:

    import foo

    foo.nonexistent()

You get a run time error.

A lot of the time with Python you will be importing classes so it will be mostly run time errors.

Yes but it gets feedback from the IDE. Cursor is the best here