End of 2016 update on PyKF5 bindings

[Shaheed Haque]

Hi Steve,

On 13 January 2017 at 19:17, Stephen Kelly <steveire at gmail.com> wrote:
> Shaheed Haque wrote:
>
>> HI,
>>
>> On 6 January 2017 at 00:33, Stephen Kelly <steveire at gmail.com> wrote:
>>> Shaheed Haque wrote:
>>>
>>>>> It is my intention to add that and other databases which are currently
>>>>> 'missing', when
>>>>>
>>>>>  * We have some tests for them in the ECM repo
>>>>>  * We want to add bindings to a framework (in a KDE repo) which
>>>>>  requires
>>>>> them
>>>>
>>>> To your first point, the bulk generator/compiler tools *are* test
>>>> tools as far as KF5 is concerned...they happen not to fit the
>>>> repository-aligned model because for my present purposes, I want to be
>>>> able to easily run them en-masse across /usr/include/KF5.
>>>
>>> Yes. I consider having unit tests in the ECM repo (and versioned with the
>>> scripts) essential.
>>
>> Sure, that makes perfect sense. But we should not confuse the goodness
>> of such tests with the need to assure a broad swathe of code can be
>> reliably processed.
>
> Are you familiar with the saying 'take care of the pennies and the pounds
> will take care of themselves'? It applies to software too.
>
> Any problematic case you find in trying to process the 'broad swathe' can be
> reduced to a testcase in ECM. This is a very basic principle of software
> testing and quality.

Yes, but it also depends on having viable output to test! Once the
stuff that I am working on is at the point where the resulting binding
actually compiles/imports/works, adding tests to ECM becomes a
possibility. Till then, I can only rely on the approach I am presently
taking.

>>> Regarding my second point above, my next target is to add bindings to the
>>> KDE ki18n repo. That will require adding the ModuleCodeDb and
>>> MethodCodeDb to ECM. I'm working on autotest extensions for those.
>>
>> Again, having self contained tests for that is fine. But my point is
>> that the ModuleCodeDb and MethodCodeDb code you need is already there
>> precisely because I was able to determine the need for it using the
>> bulk processing approach.
>
> Yes, you got quite far in determining requirements. Determining requirements
> is not the same thing as creating maintainable, unit tested software,
> however.

But it is a necessary initial step!!!!! I think the main delta between
us is that I am choosing to focus on the breadth of the requirements
by concentrating on the initial .h parsing and .sip generation. For
me, getting to actually compile the .sip, import it into Python, and
then run it are all later steps. Again, the reasoning for my approach
is to ensure that the basic design of the rules databases and so forth
are sufficiently complete to avoid the need for folk like you who pick
up this work to continually update the rules formats.

(You've done a great job in getting to the finish line in a few cases,
but I'm not there yet).

The three main areas I know I need to cover before I can declare the
rules database formats good enough that the risk of change seems small
are:

- Almost arbitrary edits to all structures that clang emits.
- Automated support for templated types such as QMap and QHash
(%MappedType et. al.).
- See what, if anything, can be done to automate %ConvertToSubclassCode.

The first is in very good shape as of a few days ago. The second (as
of this morning) produces code that can be imported by Python. The
third is not yet started (though Phil from PyQt-land has pointed me at
some sample code he has). FWIW, so far, I have identified two changes
which *could* be beneficially added to the rules databases:

- To add two extra fields in the function database to support matching
prefix and suffix keywords/decorators. I believe I can do this in a
backwards compatible fashion.
- To have handler functions return a value to suppress "nothing
changed" messages. However, the resulting warnings seem like a
qualified good thing, and my current instinct is to leave things as
they are.

Overall, I feel I am reasonably close to being done.

>> Perhaps I was not sufficiently clear in
>> https://mail.kde.org/pipermail/kde-bindings/2017-January/008391.html.
>> Your commit c05dcfa4c4f39448323c4f52fbb534867a96747c takes a subset of
>> one of the commits in the branch that I consider a work-in-progress.
>
> I see, sorry about that.
>
>> I have rewritten the history of that branch multiple times in the last
>> days, and I have no idea which of those you took. For clarity, I would
>> like to get '759 and '763 merged, and then I will queue up the other
>> changes for review.
>
> I left some information on
>
>  https://git.reviewboard.kde.org/r/129760/
>
> Can you review it and then check your review requests to see which ones can
> be closed?

Sure, I hope to take a look soon.

Thanks, Shaheed

> Thanks,
>
> Steve.
>