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

[Shaheed Haque]

Philipp,

On 3 November 2017 at 12:52, Philipp A. <flying-sheep at web.de> wrote:
> Hi Shaheed,
>
> Thank you so much for all your work!
>
>> a framework-by-framework integration of the binding generation logic (as
>> previously pioneered by Steve) probably cannot work in general because there
>> are cases where multiple frameworks contribute to to the same C++ namespace
>> […]
>>
>> The problem is that the Python implementation of these namespaces is a
>> class, and so treating these frameworks […] as separate would result in
>> multiple colliding Python class definitions.
>
>
> Am I missing something? Namespaces should be Python modules, not classes. If
> we can do represent them this way, the problem is solveable:
> https://packaging.python.org/guides/packaging-namespace-packages/

First, I am using this technique at the KF5 level (the pkg-util
version). My concerns about using it to address the namespace problem
are that:

- my overall understanding of this technique is that it may end up
being fragile, especially given the difference between P2 and P3.
- using it further down might not work as expected especially if there
are "accidental" collisions in the directory/namespace names.
- it is also not clear if the technique can be used multiple times.
- cppyy gives us classes. (Actually, in conversation with Wim, CC'd
here, it turns out that the choice of using classes is not arbitrary,
but we were pondering simple modules at that point, for other
reasons).

Bottom line: I'm not keen on using Python namespace modules here for
the reasons listed.

>> The original TODOs and bugs have been resolved, and there is the
>> beginnings of support for packaging frameworks under a Python namespace as
>> in "KF5.KDCRAW".
>
>
> Once they’re modules, we should probably respect that Python modules are by
> convention lowercase. It would be best if we named them kf5.kdcraw and so
> on.

That's likey to be a bad idea because of the potential impact on
arbitrary round trips between C++ and Python (remember that everything
is based on named-based lookups). In addition, we already have
problems like "gpgme++", and the use of capitalisation to separate
legacy and forwarding headers in KDE: further case-based confusion is
the last thing that is needed!

Thanks for the review/remarks, Shaheed

> Thank you again,
> Best, Philipp