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

[Philipp A.]

Hi Shaheed,

Shaheed Haque <srhaque at theiet.org> schrieb am Fr., 3. Nov. 2017 um
14:16 Uhr:

> Philipp,
>
> - my overall understanding of this technique is that it may end up
> being fragile, especially given the difference between P2 and P3.
>

Python 2? I’m sure we shouldn’t include into our decision making an
obsolete language that has a final (yes, really this time!) expiration date
2 years in the future. 2020 is the end of the line, I certainly don’t
bother anymore to write a single line accomodating to it, and would suggest
you do the same for a new project.

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

We should check if this is the case. Who’s a Python guru who knows the ins
and outs of the module system?

- 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).
>

I’d be interested in why. Usually using classes as namespaces is only done
for reasons of cuteness (callable namespaces, namespaces usable as context
managers, …) or so.

Even in this case, it’s possible to replace the module’s class with a
module subclass that has the necessary capabilities (modules are objects
that have a class, too)


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

I’m not entirely convinced. We should only do a final decision once we know
if either your suspicions of multiple levels not working turn out to be
true, or the reason for using classes is important.


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

I see, makes sense. I guess the allcaps example here is not very common
anyway, and most namespaces will be UpperCamelCase like Qt’s, right?

Thanks for the review/remarks, Shaheed
>

NP!
Best, Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20171103/c7a02c38/attachment.htm>