Revision history [back]

Out of curiosity, I asked Copilot to provide a response to your question (I wanted to post this as a comment because it might not be the expected answer, but since the text was too long, it got cut off.) :

When you say that you have “a working REPL that can import modules”, you are essentially reporting that the CPython interpreter embedded inside Sage is fully functional on your machine, including its ability to load extension modules compiled in C, C++, or Fortran.

A REPL (Read–Eval–Print Loop) is simply the interactive CPython shell. The important part is not the REPL itself, but the fact that this interpreter can successfully import extension modules such as NumPy, SciPy, or Matplotlib. These modules contain compiled native code and rely on specific CPU instruction sets.

On macOS 10.13 running on older Intel hardware, the system Python typically fails with errors like “Illegal instruction” or “Bad instruction” when importing modern scientific libraries. This happens because recent wheels for NumPy/SciPy are built with AVX or AVX2 vector instructions, which your CPU does not support. As soon as the dynamic loader tries to execute AVX instructions, the process aborts.

Sage does not use the system Python or system-provided NumPy/SciPy. Instead, Sage builds its own Python environment and compiles its numerical libraries from source, using compiler flags that match the capabilities of your CPU. This is why Sage’s internal Python can import these modules without triggering illegal instruction faults.

In other words:

The Sage Python interpreter is working correctly.

Its extension modules are compiled in a way that is compatible with your CPU.

The system Python fails because its extension modules require AVX instructions that your CPU does not implement.

You can use Sage’s Python interpreter to run standalone scientific scripts. Many users with older hardware do exactly this. The main caveat is that Sage’s Python environment is designed primarily for Sage itself, so internal paths and dependencies may change across Sage releases. As long as you stay on your current Sage installation, this approach is technically sound