config.optimization_level

[CEXT-Dan]

https://docs.python.org/3/c-api/init_config.html#c.PyConfig.optimization_level
is not set, should we set it?

[gswifort]

I think this could be a cool option. But as an option. I'm almost done implementing settings that are read from a config file / environment variables / .env file (pydantic_settings). It would be nice if you could get these settings in c++ so you don't have to implement it twice. The only idea I have is to run a shell script in c++ python -m pyrx.config, which will print the configuration to stdout, e.g.:

log=true
optimization_level=1
(...)

[rdesparbes]

If the C++ part also needs to access those settings, wouldn't it be more natural for the C++ to be responsible for managing them and providing an API so that the Python parts can use them?

[gswifort]

It would be more natural, but probably much more difficult. Implementing settings on the python side is not much more than this:

from pydantic_settings import BaseSettings, SettingsConfigDict

class PyRxSettings(BaseSettings):
    disable_onload: bool = False
    onload_path: Path | None = None
    load_repl: bool = False

    model_config = SettingsConfigDict(
        env_prefix="PYRX_",
        toml_file=tuple(dir_ / "pyrx.toml" for dir_ in _get_settings_file_dirs()),
    )

By default, reading settings from the environment, .env file, command line is supported (we will not support command now for now due to CAD application limitations, but it would also be doable). With a small effort, you can add reading configuration from a TOML file (e.g. settings file in APPDATA) and from the pyproject.toml file (table [tools.pyrx]). Adding another variable to the settings is simply adding a variable with a type annotation in the PyRxSettings class (one line).

[gswifort]

That's all I can say from my side, I only know python, in c++ I can only write std::cout << "Hello World!\n";😂

[gswifort]

Additionally, this library is intended for Python users, so in my opinion the more written in Python the better, but I may be wrong.

[CEXT-Dan]

That's all I can say from my side, I only know python, in c++ I can only write std::cout << "Hello World!\n";😂

like my python skill lol

[CEXT-Dan]

Tested with config.optimization_level = 2;
It strips the docstrings, I’ve read “Turns out that dropping docstrings reduces the memory usage by around 10%”
PYDEBUG still works
There’s no noticeable difference in my benchmark tests, but this only meant to give me an idea of latency between C++ and Python calls
I can see that some changes are made to the bytecode.

IMHO, it does not make sense to have full compiler optimizations options set in C++, and have optimizations turned off in Python.

My thoughts

• one of the primary features of pyrx is performance
• the default should be maximum optimization
• there should be a way to override this.
• 90% of users don’t care, they just want the performance

What are the downsides of having maximum optimizations turned on by default?

[gswifort]

I don't think I have anything against default optimization - as long as it can be changed.

And do the tests work? As far as I know, the assertions are turned off.

[CEXT-Dan]

And do the tests work? As far as I know, the assertions are turned off.
tests seem to work fine. I'll turn it back to default until we have a way to change it

[CEXT-Dan]

I’m fine with reading a config file.
I dislike searching the filesystem, or having the possibility of multiple config files, so the path should be hardcoded as
APPDATA/pyrx/pyrx.toml or something
an API can be made to change settings in Python
But we can open another discussion

[CEXT-Dan]

I made a refresh build for testing config.optimization_level 2

[gswifort]

Related: #288