[agolio]

You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part.

There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again...

Interesting to read about cling, will have to play around with that.

[nhchris]

> You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part.

That's how I understood your post. Sorry if my post came off as a correction - it was not meant as such, but as a question (not specifically about Python or C++):

How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produce a machine-code executable place on it?

Because naively, I would say it should have no effect - one could package the interpreter and source-code into a single file, and think of that as a (very unoptimized) "compiled executable".

[agolio]

It makes debugging and R&D really easy.

For example say I have a script:

  data = slow_computation()
  metrics = produce_metrics(data)

Now later I want to play with some metrics and experiment a bit I can do that in the interactive shell (running with python -i file.py will run the script as normal but leave a python interpreter open at the end with all the variables kept alive)

When I am happy with my experimentation results, say, I have found something interesting about the data and written a new function cool_metric(metrics) I can commit it to the script at the end

  data = slow_computation()
  metrics = produce_metrics(data)
  cool_metric = cool_metric(metrics)

There's also the ability to drop in breakpoints where you can then have the full python shell available, can break out of the debugger into an interactive shell if you want, or can modify a variable and then continue the script as normal. I think you can do that with GDB for instance but it's not quite as flexible if I am not mistaken?

so if I have

  def some_buggy_function(args):
      data = analyse(args)
      breakpoint()
      new_data = further_analyse(data)

that can be quite powerful in making debugging easy

[DougBTX]

> How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produce a machine-code executable place on it?

“Compiled” is being used as a short-hand for “compiled with optimisations”, so yes, an unoptimised build wouldn’t count here.

The design decision is around when (between the code being written and being run) is the final decision made about what exact code will run. If that is known really early (static types, no dynamic dispatch) then optimisations can be made early too. If it is really late (polymorphic methods, support for redefining types etc) then optimisation needs to run very quickly (“just in time”) or not at all.

If you want to go deeper on this, look at performance optimisation in Julia. It has the same LLVM backend as C/Rust, so can use all the same optimisations, but it is arguably a more dynamic and easier to use language than Python, so when and how optimisations apply really depends on how the code itself is written. As a bonus, it has some great tooling to see how changes to the code impact performance.