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

[Shaheed Haque]

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?
>
> 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