Python bindings using cppyy (was: An update on Python bindings)
srhaque at theiet.org
Sat Nov 4 17:35:05 GMT 2017
On 4 November 2017 at 16:45, Philipp A. <flying-sheep at web.de> wrote:
> Hi Wim!
>> 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 paths,
>> 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”?
FWIW, I already tried that (types.ModuleType is itself a perfectly
subclassable class!) in the case where the framework had the form
<simplename> and that worked fine. I did not pursue this for the case
where the framework name if "KF5.<simplename>", i.e. the case where
the shared namespace comes into the picture because of these
statements on https://packaging.python.org/guides/packaging-namespace-packages/
under the native Python3-only case:
- "It is extremely important that every distribution that uses the
namespace package omits the __init__.py or uses a pkgutil-style
__init__.py. If any distribution does not, it will cause the namespace
logic to fail and the other sub-packages will not be importable."
and under the Python2/3 compatible pkg-util case:
- "The __init__.py file for the namespace package needs to contain
only the following:
__path__ = __import__('pkgutil').extend_path(__path__, __name__)
Every distribution that uses the namespace package must include an
identical __init__.py. If any distribution does not, it will cause the
namespace logic to fail and the other sub-packages will not be
importable. Any additional code in __init__.py will be inaccessible."
Now, none of that may be a limiting factor in the plan you seem to be
discussing, but it was part of what made me think "here be dragons"...
> Thank you for explaining,
> Best regards, Philipp
More information about the kde-core-devel