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

[Shaheed Haque]

Hi Philipp,

On 3 November 2017 at 14:09, Philipp A. <flying-sheep at web.de> wrote:
> 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.

The key issue for me has only ever been to get to usable bindings for
Kate, via the necessary stepping stone of KF5. My observation is that
*nobody* is likely to help with that problem: the framework owners did
nothing obvious to either keep PyKDE4 going (out of tree) or to help
Steve with my earlier SIP based efforts (in tree).

In that context, this is a low level issue I'm not especially excited by.

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

To be clear, I'm not that guru.

Having said that, the comment about Python2 is a missing the the key
point that the separated namespace stuff relies on what seems to me to
be an intrinsically fragile name-of-directory based scheme. Arguably,
the P3 version is even more fragile in this respect.

Worse, the (limited) commentary on the web suggests that the core
Python devs not only got this "wrong" in Python2, there is an
awareness that the Python3 solution has its own issues. That's enough
to scare me away from building a deep dependency on it!

My usage of the for the KF5 namespace level is based on the low
probability of a collision on that name, and the only reason I
mentioned Python2 is that I chose the scheme that supports both P2 and
P3. If you are right, and P2 is never an issue, it should be fine. I
do however prefer to maintain compatibility until the burden of doing
so presents an insurmountable issue.

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

Feel free to discuss with Wim (it has something to do with
serialisation of classes and there are some interesting grottos to do
with __module__ naming to consider too). I don't propose to follow
this up. FWIW, this came up because of some substantive issues to do
with __module__, and the approach I now have in hand, based on
discussions with Wim, will be largely decoupled from this topic, and
so the way is open for anybody who does care to take this forward.

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

Yes, I'm well aware of some of those possibilities as I've tried
several of them :-).

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

There is no need for a "final decision" from me. I would suggest that
the first question for anybody that cares is to assess the scope of
the issue. Unfortunately, i have other more fundamental issues to fry.

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

Ack. So far (and based on my experiences with the SIP work), I started
with something very simple (KDCRAW), and moved onto one of the worst
cases (Akonadi). I won't be in a position to gain a wider perspective
until these two are working solidly.

Best regards, Shaheed

>> Thanks for the review/remarks, Shaheed
>
>
> NP!
> Best, Philipp