Proposal: Replacing YAML with Python
This is a quick dump of the brainstorming session where I proposed the YAML file could be replaced with a Python file.
This would allow
-
Similar syntactic ease to yaml
-
Improved customization ability by being able to execute runtime postprocessing on result of C++ calls.
The idea is given a CPP file, perhaps you define some before.py file that specifies any configuration that would have existed in the YAML file
import autopybind
autopybind.wrap_definitions_from_local_cpp_files()
defs = autopybind.wrap(
'''
files:
non_template/derived2.hpp:
namespaces:
nmspc1:
namespaces:
nmspc2:
classes:
Derived2:
protectedClass:
functions:
call_virt_from_derived2:
'''
)
class Customization(defs['nmspc1.nmspc2.Derived2']):
pass
__autopybind__ = {
'namespace': 'nmspc1.nmspc2',
'file': 'non_template/derived2.hpp',
}
class Derived2:
"""
Custom documentation for my python binding
Example:
>>> self = Derived2()
>>> self.custom_behavior()
# TELL the user what to expect on the PYTHON side
"""
__autopybind__ = {
'functions': [
'call_virt_from_derived2',
]
}
def custom_behavior(self):
x = self.call_virt_from_derived2()
x = x + 1
return x
And then this either generates an "after.py" file in the build directory:
from _derived2 import _APB_Derived2
class Derived2(_Derived2):
"""
Custom documentation for my python binding
"""
def custom_behavior(self):
x = self.call_virt_from_derived2()
x = x + 1
return x
That is either a modified version of the before file, or ideally the same exact file (which would allow for symlinking the source to the build tree and make hacking on the python bindings easier).
The above code is psudocode and contains half-baked ideas for what the syntax of the code would be.
At build time autopybind would
-
read the python configuration file (either dynamically, maybe via
ubelt.import_module_from_file
) or statically (via parsing it with Python's builtin AST module). -
use the information to gather the information needed to generate the real pybind11 CPP code.
-
compile the real pybind11 CPP code into a private / protected
_after.so
python module. -
The
after.py
file imports the_after.so
module and does any python-side manipulations that need to occur to cleanly manage the CPP data structure (if there needs to be any of these at all).
This idea is quite raw and there are lots of things that could be enhanced given a basic implementation (e.g. seemless access to templated data types based on either runtime type introspection or explicit __getattr__
methods).