jack.jan...@cwi.nl writes: > I’m getting increasingly worried about the future of Python,
You mean about the fact that Python has a plethora (rapidly growing!) of powerful, efficient extension packages and you want to use them all (perhaps recursively)? :-) I really don't think this bodes ill for the future of Python. Perhaps it bodes poorly for your development practices (and I'll try to tease out some ideas where we can improve the infrastructure for you), but there are plenty of applications where this plethora works really well, too. > and those worries have been exacerbated by the new yearly release > rhythm, and the lack of a stable C-API that is full enough to > entice extension writers to use it. I don't think "full API" is the problem (cf. Phil Thompson's post[1], where the stable API is good enough for PyQt). I think the problem is more likely that in initial development, they simply targeted the .h files in front of them.[2] Since then they haven't needed to update, and *neither has anyone else with resources or pull with with that package's devs*. Suggestion: Perhaps the documentation can be improved to make the stable API easier to conform to from the get-go. (I think the stable API is already distinguished in the .h files.) If "full API" *is* the problem, I doubt it's a solvable problem (except by extension users lobbying extension developers to use the stable API), because the stable API is a deliberate compromise between efficient communication between CPython and extensions, and flexibility for CPython to improve its internal implementation. If extension writers *deliberately* eschew the stable API, presumably they need to access private APIs and if those change, too bad. > And I also fully understand that some other developer who creates a > new package that is essential to my application only targets the > current Python release, This is where developers in your position can have the most impact, I think. When there's a new gotta-have extension, tell the extension's developers you need support for the stable API or ABI, or you can't use their package. > And that is assuming you have the time and are smart enough to back > port the new package to the old Python release, or the old package > to the new Python release (and for the latter there’s probably a > good reason why the developers haven’t done so already). Most frequently, as you pointed out, the reason is that they're busy with other priorities, and it's just not their itch to scratch. > I think we really need to come up with some scheme whereby > extension packages become more long-lived than a single Python > release... I would guess that a lot of extension packages are quite long-lived. First, as Phil Thompson points out for PyQt[1], the content of the wheel may very well work fine, but they have to actually make the wheels with the appropriate name (or maybe other metadata?), or they won't install in the new Python version's site-packages. I think this is something that Python (distutils-sig) could do something about, either by adding a way to make multi-version wheels, or providing a utility to retarget an existing wheel (maybe mv(1) is enough?!) Second, I'm sure there are plenty of extensions that can be ported to either new CPython versions or (preferably) to the stable API or ABI with minimal effort. Perhaps there could be a SIG or a channel in the tracker where people could request these ports. I'm suggesting this because of the "better things to do problem". Obviously, if the extension itself is unmaintained, its maintainer will do nothing. Even if it is maintained, it seems that its dev community does not prioritize these ports. But new developers looking for something to do might see it in "core" channels. Probably there are plenty of people around who can help them build wheels, and I believe a significant fraction of extensions without current version wheels will require little or no C changes. (OK, this doesn't involve a merge request to CPython, so it doesn't immediately set them on the path to core dev status, but we can award gold stars.) Footnotes: [1] <https://mail.python.org/archives/list/python-dev@python.org/message/RPDUNMG6RS4FBG6GODZDZ4DCB252N4VP/> [2] Maybe that's just me? OK, I'm busted! _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BKAZWGLTLOZ6BJDC3KAYBWTITFO4BQN4/ Code of Conduct: http://python.org/psf/codeofconduct/
