[PyQt] Empty and template classes

[Shaheed Haque]

I just wanted to highlight the SIP-does-not-like-empty-classes
part of this thread. Is that something that could be addressed please?

On 10 April 2016 at 18:51, Phil Thompson <phil at riverbankcomputing.com> wrote:
> On 10 Apr 2016, at 5:52 pm, Shaheed Haque <srhaque at theiet.org> wrote:
>>
>> Hi Phil,
>>
>> On 10 April 2016 at 16:40, Phil Thompson <phil at riverbankcomputing.com> wrote:
>>> On 10 Apr 2016, at 2:53 pm, Shaheed Haque <srhaque at theiet.org> wrote:
>>>>
>>>> Hi Phil,
>>>>
>>>> On 10 April 2016 at 13:32, Phil Thompson <phil at riverbankcomputing.com> wrote:
>>>>> On 10 Apr 2016, at 1:21 pm, Shaheed Haque <srhaque at theiet.org> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> One enhancement request, and a question. First, SIP 4.16.9 does not
>>>>>> like empty classes like this:
>>>>>>
>>>>>> class KUserOrGroupId
>>>>>> {
>>>>>> };
>>>>>>
>>>>>> The above results in a syntax error. Adding anything makes it work, for example:
>>>>>>
>>>>>> class KUserOrGroupId
>>>>>> {
>>>>>> %TypeHeaderCode
>>>>>> #include <KCoreAddons/kuser.h>
>>>>>> %End
>>>>>> };
>>>>>>
>>>>>> is accepted. It would be nice to have support for this corner case.
>>>>>> Second, the syntax for template classes does not seem to work as I
>>>>>> expected. This example results in a syntax error, as does every
>>>>>> variation I could think of (including trying to match PyQt):
>>>>>>
>>>>>> template <typename T>
>>>>>> class KUserOrGroupId<T>
>>>>>> {
>>>>>> %TypeHeaderCode
>>>>>> #include <KCoreAddons/kuser.h>
>>>>>> %End
>>>>>> };
>>>>>>
>>>>>> Like the function case, I realise the implementation for this is not
>>>>>> trivial (templated methods and the like), but I cannot seem to make
>>>>>> the basic syntax work. It should, right?
>>>>>
>>>>> See...
>>>>>
>>>>> http://pyqt.sourceforge.net/Docs/sip4/specification_files.html#syntax-definition
>>>>>
>>>>> ...also look at the PyQt .sip files.
>>>>>
>>>>> In this case, omit 'typename'.
>>>>
>>>> I tried (having reviewed the syntax page and parser.y) several
>>>> variations such as this:
>>>>
>>>> ====
>>>> %Module test_template
>>>>
>>>> template <T>
>>>> class KUserOrGroupId<T>  <<< line 4
>>>> {
>>>> %TypeHeaderCode
>>>> #include <KCoreAddons/kuser.h>
>>>> %End
>>>> };
>>>> ====
>>>>
>>>> which does not work. However, it *does* work if I discard the "<T>"
>>>> from line 4, or use %MappedType. What is eluding me are the rules I
>>>> need to follow for references to T within the class. For example,
>>>> let's say the class contained a method with the signature:
>>>>
>>>>   void foo(T *bar);
>>>>
>>>> If I understand correctly, the semantics of passing T in are knowable,
>>>> but SIP does not like the "T", and I have not been able to work out
>>>> how the signature for foo should be written to get it past the syntax
>>>> errors. Is a template class able to support things like this (once I
>>>> implement the %MappedType)?
>>>
>>> I honestly can't remember if it's supposed to work or not. What's the error when SIP 'does not like the "T"'?
>>>
>>> I would actually approach it from the other end - first of all how do you want to represent KUserOrGroupId in Python?
>>
>> The error from SIP is simply "syntax error" [1].
>
> Methods in a MappedType must be static.
>
>> But you ask an apposite question and in truth, I don't yet know, yet.
>> The point is that SIP for KF5 (ad KDE generally) is a substantial
>> undertaking for which I am attempting to develop an automated approach
>> [2]. At this point, I'm trying to limit how deep I go in favour of
>> breadth and trying to get *some* bindings working.
>>
>> Trying to get enough of the generated SIP to run through the syntax
>> phase at least seems important to me to ensure the overall automation
>> approach is sound (this is not something I consider proved yet). This
>> seems critical to me because the inability to sustain the maintenance
>> effort on PyKDE4 seems to me to be the root cause that KDE 5 has no
>> bindings.
>
> I completely agree.
>
>> It may be that this ends up being unrealistic, and I end up having to
>> go deep and perhaps generate manual code for some of the base classes
>> before anything useful can be made to work, but I'm not quite there
>> yet.
>
> The way I started to do it (many, many years ago) was to pick a simple, complete C++ example a do enough to be able to run a Python version of it. I then expanded the depth and the breadth as required.
>
> Phil