I'm afraid that's the only way to go if you want to support both past and future Sailfish OS releases - there is either just libpython 3.4 in SFOS <3.0.2 and only libpython 3.7 in SFOS >= 3.0.2.

To be clear I don't think Python was ever specified as a stable API on the Python library level. And while I had to fix modRana for Python 3.7 it was just a ~5 lines where "async" was used a method argument.

Also, this is basically what distros like Fedora do - a new version of Python is built (recently 3.7, the same Sailfish OS picked up) and all packages using get rebuilt, multiple version of libpython are never carried at the same time.

This is of course easier to do for a fully open source distro where all the packages are built on the Fedora run build infrastructure. A bunch of automated scripts with some proven-package intervention will take care of all the rebuilds in a day or two.

This is unfortunately much harder to do on Sailfish OS as both Harbour/Jolla Store and Open Repos still support only binary package uploads, even for fully open source apps that might even be built on the Mer OBS in the first place.

At least the Jolla store IIRC has a feature where you can specify that a given package upload requires a minimal package version. This might be similar to how in Fedora you might want to only update a package in Fedora 29, but skip doing that on Fedora 28 due to outdated libraries. But I'm actually not sue how the feature really works in the Jolla store - do people on older Sailfish OS releases get an older package version ? Or won't they see the app at all until they upgrade the system ? Not sure.

And Open Repos AFAIK does not really have a notion of SFOS releases & no such per-release options (unless you basically create two separate project pages I'm afraid, or do some nasty hacks in the packaging).

In any case, this is yet another thing that would be fixed by native apps being distributed via Flatpaks. Major lungiage runtime/library updates like this would (I would at least hope! ) trigger the creation of a new base runtime (with Python 3.7 and any new updated incompatible libs) while the previous runtime with Python 3.4 would still be supported for a while, giving application authors enough time to migrate to the new runtime. For users this would be totally transparent - they would simply get the new runtime installed during an app update once an apps starts requiring it. The old runtime would presumably be automatically uninstalled once the last applications stops using it,