kdev-python: plans to add support for PyQt6 & PySide2/6 ?

[mail at flherne.uk]

On 2024-01-03 06:57, Björn Strömberg wrote:
> On Tue, Jan 2, 2024 at 10:11 PM Sven Brauch <mail at svenbrauch.de>
> wrote:
> 
>> Hi,
>> 
>> a word of caution, I haven't looked at these bindings for about ten
>> years, which is also approximately how outdated they are.
> 
> yea i know the bindings are out of date, its visible by the datestamps
> on the folders,
> that was the reason for the question of autogenerating them on build
> instead,
> might be a bit more work upfront but should payoff in the long run..
> 
> one thing with open source is the fact that sometimes you just have to
> get into it and try to help out when stuff you need seems to be stuck
> in the mud, or aleast stuck in the mud from your P.O.V..
> 
> I will try to see if i can help out some, mainly cause it seems like
> PySide2/6 will be a solution to help me be more productive (C++/Qt dev
> with to much work and to little time),
> now i need the tooling, and that part is currently based on getting a
> working Alpine Linux - KDE Environment (preferably before 24.02
> release),
> to get that i need i need a working KDevelop with Python support..
> 
> by now our paths have crossed, now my process is to get to know where
> kdev-python is heading and if i need to hardfork or if we can get
> along and it will be better for all..
> 
> i would prefer not to have to maintain a separate fork, but that
> requires to work with current maintenence 'crew' and so far you seem
> reasonable so i think it will work.
> 
> this is the reason for this mailing list 'thread', to find out of this
> project actually still is viable or if a fork is the only way forward.
> 
> i got about two months (deadlines for 24.02) where I'll use some free
> time for this project to advance my 'Alpine Linux' context where i
> will have to maintain custom application repositories on top of their
> main for private reasons.
> 
>> On 02.01.24 09:33, Björn Strömberg wrote:
>>> the process as i see it (for KF5/KF6 in case they do not have
>> python
>>> wrappers like pyside) we got the qt tools to generate pyside2/6
>>> 
>>> * shiboken2 https://doc.qt.io/qtforpython-5/shiboken2/index.html
>>> <https://doc.qt.io/qtforpython-5/shiboken2/index.html>
>>> * shiboken6 https://doc.qt.io/qtforpython-6/shiboken6/index.html
>>> <https://doc.qt.io/qtforpython-6/shiboken6/index.html>
>>> 
>>> to generate the python interfaces, then what we need is something
>> to
>>> read those interfaces to create the manuals,
>> 
>> I'm not sure we're talking about the right thing here. We don't need
>> to
>> generate the bindings, other people have already done that, we only
>> need
>> to generate files containing the relevant definitions and docs in
>> the
>> right format for kdev-python to understand. This format is the
>> "header-like" files you've found.
> 
> the KF5 / KF6 binding question is for the fact i can't seem to find
> any upstream of that, it does not seem to be a PyKF5 that KDE supplies
> as official..
> https://github.com/blackPantherOS/frameworks-bindings/tree/master &
> https://github.com/steveire/frameworks-bindings this testings are
> ~8years old now..
> 
> and duckduckgo cant seem to find anything useful on the subject, this
> is the only thing i get on google that is somewhat close..
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/37
> 
> if we're serious about having kdev-python and PyQt6/PySide6 support,
> then there should actually be a python binding support for 'our' KDE
> Frameworks that build on top of them, but where are they?
> does every kf-module build its own bindings?
> 
> the reason there is no KF5 bindings that are seem supported is the
> reason I've keept away from Python + Qt, dont see the reason to
> reinvent the wheel if someone actually have done the binding work for
> KF5/6..
> 
>> They used to be generated from the SIP description files for PyQt,
>> and
>> from a quick glance it looks like that could still work in
>> principle.
>> The scripts to do that are in the "documentation_src" folder, but
>> will
>> certainly need some changes (apparently the SIP command line
>> interface
>> has changed and the files have also moved, but maybe there are more
>> rocks in the way).
> 
> no clue what SIP is? the closes i get from a search engine: Session
> Initiation Protocol (SIP)
> 
> but that seems to be the wrong context.. there is no actual
> description files in documentation_src folder, i can find a notes.txt
> that seems incomplete..
> so i guess its something somewhere in the documentation process like
> doxygen 'IR' output somewhere, but i have not digged deep in that area
> yet.
> 
>> Feel free to have a look if you are interested, or alternatively in
>> the
>> next months I'll need to do a bit of maintenance anyways to add
>> support
>> for Python 3.12, then I can also see if I can update those scripts
>> to
>> support PyQt6 and current SIP. No promises though ;)
>> 
>> Greetings,
>> Sven
> 
> I'll dig into the problem and see if i can untangle the process of how
> to actually do the full process, if you can fill in more on the
> process and where to look it would be appriciated..
> 
> when i get the full process of how its done, it can be automated, then
> we need to decide how to automate it and the way there...
> 
> Greetings
> Björn

Hi Björn,

SIP in this context is a tool used to generate Python bindings for C++ 
code, and in particular to produce PyQt:
https://www.riverbankcomputing.com/software/sip/
https://en.wikipedia.org/wiki/SIP_(software)

pyside's Shiboken that you've linked appears to be roughly equivalent 
although I'm not familiar with it.

When the documentation stubs were last touched, Qt support/control of 
pyside didn't exist. PyQt was far more mature and the obvious choice of 
bindings. It's been years since I used Qt from Python code, it looks 
like pyside/"Qt for Python" has come on a lot in the meantime.

The KF5 Python bindings were generated for each library using SIP via 
some KDE-wide CMake tooling, but regrettably seem to be dead now:
https://mail.kde.org/pipermail/distributions/2022-February/001148.html

Projects with Python bindings generated by SIP come with `*.sip` files 
that describe their API,
for example under sip/ in the PyQt source 
https://pypi.org/project/PyQt6/#files

These were read and converted by documentation_src/pyqt/generate.sh 
(using the python scripts in the same dir) to produce the current 
outdated PyQt stubs.
Looking at the old scripts might be helpful but they're *long* dead and 
won't work. You're probably better off starting from scratch whatever 
you do.

At the time these stub files were generated there was no upstream 
solution, so they're a kdev-python-specific hack.

The long-term solution would be to improve kdev-python's support for 
PEP-484 type hinting and have it parse `*.pyi` stub files which are the 
newer, upstream-supported solution with a lot of tooling behind them.

PySide, PyQt and numpy all provide `*.pyi` stub files so kdev-python's 
own format would be entirely obsolete if we supported these properly.
There would be no need to generate, ship or parse our own stubs and they 
could be removed entirely.

It would also significantly improve kdev-python's support for other 
libraries using standard `*.pyi` files for which kdev-python has never 
had stub files.

Unfortunately support for PEP-484 (and successors) typing is a major 
project that would require a lot of digging into KDevelop and 
kdev-python internals. I believe it's possible, and once intended to 
implement it but have been occupied with other things outside KDE.

I'm happy to discuss stuff by email (as I'm sure Sven is) or on IRC 
where I'm FLHerne.

It's good to see someone new taking an interest in kdev-python!

Yours,
-Francis Herne