Python bindings using cppyy (was: An update on Python bindings)
srhaque at theiet.org
Sun Nov 5 01:19:15 GMT 2017
There is a POC-quality implementation of the integration with KDE here:
This contains examples of bindings for Akonadi and KDcraw. My next
steps will be to do a few more, and then move on to the TODOs listed
On 4 November 2017 at 17:35, Shaheed Haque <srhaque at theiet.org> wrote:
> Wim, Philipp,
> 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