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 :)
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.
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
(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).
> (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.