Re: Python bindings using cppyy (was: An update on Python bindings)

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 <[email protected]> wrote:
> Wim, Philipp,
>
> On 4 November 2017 at 16:45, Philipp A. <[email protected]> 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