Bug 500728

Summary: Add python bindings for kpublictransport
Product: [Frameworks and Libraries] KPublicTransport Reporter: Max Buchholz <Max.Buchholz>
Component: generalAssignee: Volker Krause <vkrause>
Status: REPORTED ---    
Severity: wishlist CC: nicolas.fella
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Max Buchholz 2025-02-25 14:25:30 UTC 
SUMMARY

It would be handy to have kpublictransport available as python package, as it already supports plenty of backends and provides a decent maturity. This would allow to make use of kpublictransport in Python, as there is afaik no similar package, that provides this wide range of support for Python developers. This would also allow to easily use it in Data Science or Machine Learning related fields, or provides easy access for beginners. And of course I would use it too ;)

I would also be happy to contribute to this, if there you would agree :)
Comment 1 Volker Krause 2025-02-25 16:02:37 UTC 
That has come up before, we could do that indeed.

There's multiple ways on how to approach this, just from looking at other examples in KDE:
* Using the PySide/Shiboken way used in KDE Frameworks (e.g. https://invent.kde.org/frameworks/kcoreaddons/-/tree/master/python)
* "Hand-made" bindings e.g. via Boost.Python as done here: https://invent.kde.org/libraries/kopeninghours/-/tree/master/PyKOpeningHours

The former would have the advantage of wider use in KDE and thus easier maintenance, however I don't know whether that will result in "good" bindings here, ie. no unnecessarily exposed Qt types etc.
Comment 2 Nicolas Fella 2025-02-25 16:29:11 UTC 
If the goal is to create custom UIs using Python (and Qt) then PySide bindings make sense.

For anything else it might make more sense to do a from-scratch implementation instead of dragging Qt into it. I'd see the main value of kpublictransport in the data about providers, not necessarily the implementation to talk to them
Comment 3 Volker Krause 2025-02-25 16:39:12 UTC 
(In reply to Nicolas Fella from comment #2)
> I'd see the main value of kpublictransport in the data about providers, not necessarily the implementation to talk to them

The data about providers is already a separate project (https://github.com/public-transport/transport-apis), KPublicTransport only holds a copy of that (there's still some minor differences, but that's bugs rather than features).
Comment 4 Max Buchholz 2025-02-26 16:27:48 UTC 
> (In reply to Nicolas Fella from comment #2)
> > I'd see the main value of kpublictransport in the data about providers, not necessarily the implementation to talk to them

For me it's actually exactly that: Instead of rewriting the logic to talk to different kinds of providers again in python, I would rather prefer to use kpublictransport. Of course if it is harder to maintain the bindings, compared to a separate implementation, this doesn't work out.