Python Interpreter Management

Description

This component handles the setup and basic management of the embedded Python interpreter used for extending FERS functionality. It performs the following key tasks:

• Initializes the Python interpreter when first needed.
• Checks that the available Python version meets the compatibility requirements (currently 3.7.0 up to, but not including, 3.12.0).
• Adds the current execution directory (.) to Python's sys.path to help locate user scripts.
• Provides base functionality (via the PythonExtension class) for loading Python modules and functions, managing Python object reference counts correctly.

Assumptions

• Assumes a compatible Python version (within the 3.7.0 to 3.11.12 range) is installed on the system and can be found by the FERS executable (e.g., it's in the system PATH or the necessary libraries are linked).
• Assumes user-provided Python scripts (.py files) are located either in the directory where FERS is executed or in a location already part of the standard Python search path (sys.path).
• Assumes the module and function names specified in the FERS configuration (e.g., XML files) correctly match the names within the user's Python scripts.
• Assumes the Python environment being used does not have conflicting dependencies that would prevent FERS's required Python operations from succeeding.

Limitations

• Strict Versioning: The system explicitly checks for Python versions between 3.7.0 and 3.11.12 (inclusive). It will fail to initialize and report an error if the detected Python version is outside this range, specifically blocking versions 3.12.0 and newer due to potential API changes.
• Limited Path Management: Only the current execution directory (.) is automatically added to Python's sys.path. For more complex project structures where Python scripts reside elsewhere, users may need to manually configure the PYTHONPATH environment variable before running FERS.
• Basic Error Reporting: Errors encountered during Python initialization or execution (e.g., module not found, function errors) primarily rely on Python's standard error printing (PyErr_Print to stderr) and are often wrapped in C++ std::runtime_error exceptions. This might provide limited diagnostic information directly within the FERS logging system for end-users.
• Global Interpreter Lock (GIL): Python's GIL may become a performance bottleneck if multiple C++ threads in FERS attempt to call Python extension functions frequently and concurrently. The GIL generally restricts true parallel execution of Python bytecode within a single process.

Related Components

• python_extension.cpp::python::initPython() (Handles interpreter initialization and version check)
• python_extension.h / python_extension.cpp::python::PythonExtension (Base class providing common functionality for loading modules/functions and managing Python objects)

Validation Status

• Needs Verification: Robustness of initialization and error handling across different platforms (Windows, Linux, macOS) and Python environments (e.g., standard install, Conda, venv). Actual performance impact of the GIL under concurrent usage scenarios relevant to FERS (e.g., many platforms using Python motion).
• Key Areas for Validation:
  • Test initialization with various compatible Python versions (e.g., 3.7, 3.9, 3.11) on different operating systems.
  • Verify failure behaviour with incompatible Python versions (e.g., 3.6, 3.12).
  • Test error handling for common issues: missing Python modules, incorrect function names, errors within the Python script itself. Assess clarity of error messages.
  • Investigate methods for allowing users to specify additional Python search paths more easily than relying solely on PYTHONPATH.
  • (Optional/Advanced) Profile FERS execution with heavy use of Python extensions across multiple threads to quantify potential GIL limitations.
• Priority: Medium (Core infrastructure for extensions, but known limitations exist)