Python bindings using cppyy (was: An update on Python bindings)
flying-sheep at web.de
Sat Nov 4 16:45:27 GMT 2017
So now I have a (C++) namespace 'A' that bears no relationship to anything
> to do with the file system or any type of Python packaging: it exists only
> in memory for the duration of the python session.
Yeah, cool, so we just use a path hook and are ready to go right?
Every framework gets its own path hook that handles imports from that
Frameworks with shared namespaces will just handle their own specific
The renaming does not actually scare me that much from a performance point
> of view: already, C++ has typedefs for classes and aliases for namespaces.
> There is always the problem of "leakage" as mentioned above, where the
> end-user sees both at some point, but internally, aliasing will work fine:
> it's just another reference to the same object.
Cool, so this might be possible after all! Certainly not as a top priority
before getting things to work, but still!
It is to attach a meta class for a __getattr__, the use of properties, and
> to allow pickling. The module type does not support meta classes.
Can't we replace the framework modules’ type with a subclass of both
“module” and “type”?
Thank you for explaining,
Best regards, Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-core-devel