There is a POC-quality implementation of the integration with KDE here: https://cgit.kde.org/pykde5.git/tree/?h=srhaque-cppyy-bindings&id=19a94fb3ae2b40a985913ed4e49400e02df56dc2
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 earlier. On 4 November 2017 at 17:35, Shaheed Haque <srha...@theiet.org> wrote: > Wim, Philipp, > > On 4 November 2017 at 16:45, Philipp A. <flying-sh...@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? >> >> https://www.python.org/dev/peps/pep-0302/#specification-part-2-registering-hooks >> >> Every framework gets its own path hook that handles imports from that >> framework. >> >> Frameworks with shared namespaces will just handle their own specific paths, >> right? >> >>> 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"... > > Shaheed > >> Thank you for explaining, >> Best regards, Philipp
