Colour is probably a great addition.
Gonna have to think on Attrs(and the like), not sure it’s needed don’t really want people creating long term objects in python. Mainly writing logic for how already defined objects in c++ that have bindings interact. The main rub on Attrs is how i’m abusing python. In order to maintain multi-threading (the entire reason for writing the engine in c++ and not python), i have any c++ thread create its own sub interpreter, allowing for multiple python scripts to be running at the same time, without the pesky gil crashing my multi-threading party. The problem this creates is there is no shared python state between threads, and im clearing the interpreters state also after running a script, to set it up for a different script. There is no risk of python only objects being used from two different threads here since they are tied to different interpreters, and the way my bindings are setup, i have the c++ class’ already setup for multi-threaded use.
You could think of a script being a definition to a function, and the engine would load the python file containing it and run it. then clean up the interpreter state. Basically say there is a player function walk() that will be a pyhton script, allowing anyone to modify it. without having to write c++ code and recompile the whole game. The engine is taking a clean interpreter wrapping the player and putting it in the threads python interpreter global variables, along with wrapping other c++ objects of relevance and adding them also to the globals, then executing the python script in this setup environment.
Via bound methods you will be able to add to the c++ state, but the python state can be though of as temporary stack state, that will be discarded at the end of the script. Not sure defining many classes will be necessary.