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

"Philipp A." <[email protected]>
Newsgroups gmane.comp.kde.devel.bindings,gmane.comp.kde.devel.core,gmane.comp.kde.devel.frameworks
Message-ID <CAN8d9gkML_totKf0rN6oqYK_husRT3SnPSpuEbc3RtSaC1oS=g@mail.gmail.com>
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”?

Thank you for explaining,
Best regards, Philipp
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.