[Python-Dev] Re: Changing exception text in micro releases
24.09.21 16:51, Eric V. Smith пише: > This is clearly an improvement. My question is: is it okay to backport > this to 3.9 and 3.10? I think we have a rule that it's okay to change > the exception text, but I'm not sure how that applies to micro releases > (3.9.x, 3.10.1). I am sure that it will break someone's tests. Since the current error message is not wrong, it is not a bug fix. If you want it very much you can discuss backporting to 3.10.1 with Pablo. Few people will upgrade immediately after releasing 3.10.0, and for others this change will be a part of upgrading to 3.10. But 3.9 is mature enough for now. ___ 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/OSL4OGXHBCJ27K4V7HPFZIYIQACEY2EA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Worried about Python release schedule and lack of stable C-API
I’m getting increasingly worried about the future of Python, 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. PyPI packages and wheels are targeted to specific Python versions, which means that any project that depends on some of the larger extension packages (of which there are many, and many of which are must-have for many projects) now start lagging Python versions by years, because somewhere deep down in the dependency graph there is something that is still stuck at Python 3.8 (for example). I fully understand that 3.8 is good enough for the developers of that package, and that they have more pressing things to do than porting to 3.9 or 3.10, but it now keeps any project or package that depends on their software on 3.8 as well. 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, or maybe one release back, but now if I need both the new package and and older one I’m up the well-known creek without a paddle. Building packages from source has become pretty much impossible nowadays, especially if your project is multi-platform and needs to interface to specific hardware, and you want to do the right thing with CI/CD builds and all that. On Linux/MacOS you have a chance when you try to specify all the dependencies for third party libraries and what not, but on Windows you’re dead in the water. 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). Before you know it you have to install a couple of graphics card APIs for some obscure AI feature used by something you’ve never heard of, Cython for something else, and obscure vendor libraries for something else again. I think we really need to come up with some scheme whereby extension packages become more long-lived than a single Python release... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ 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/7ALUHJBJCZGFGXHK6TTDDR3ST4YVSAWR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API
On 2021-09-26 00:14, jack.jan...@cwi.nl wrote: I’m getting increasingly worried about the future of Python, 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. PyPI packages and wheels are targeted to specific Python versions, which means that any project that depends on some of the larger extension packages (of which there are many, and many of which are must-have for many projects) now start lagging Python versions by years, because somewhere deep down in the dependency graph there is something that is still stuck at Python 3.8 (for example). I fully understand that 3.8 is good enough for the developers of that package, and that they have more pressing things to do than porting to 3.9 or 3.10, but it now keeps any project or package that depends on their software on 3.8 as well. 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, or maybe one release back, but now if I need both the new package and and older one I’m up the well-known creek without a paddle. Building packages from source has become pretty much impossible nowadays, especially if your project is multi-platform and needs to interface to specific hardware, and you want to do the right thing with CI/CD builds and all that. On Linux/MacOS you have a chance when you try to specify all the dependencies for third party libraries and what not, but on Windows you’re dead in the water. 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). Before you know it you have to install a couple of graphics card APIs for some obscure AI feature used by something you’ve never heard of, Cython for something else, and obscure vendor libraries for something else again. I think we really need to come up with some scheme whereby extension packages become more long-lived than a single Python release... You mean, something like the Python ABI (PEP 384, Stable Application Binary Interface)? ___ 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/WFGX4ZRIRXQK4NZ6JSRZRQT7463FGFVG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API
On Sat, Sep 25, 2021 at 5:40 PM wrote: > PyPI packages and wheels are targeted to specific Python versions, which > means that any project that depends on some of the larger extension packages > (of which there are many, and many of which are must-have for many projects) > now start lagging Python versions by years, because somewhere deep down in > the dependency graph there is something that is still stuck at Python 3.8 > (for example). Can you give some examples of the packages you're thinking of, that are prominent/must-have and stuck on years-old Pythons? -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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/YF7Z4EDN3DHBKPMYCIJFTI2JDTIJYHXW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API
On Sun, Sep 26, 2021 at 01:14:18AM +0200, jack.jan...@cwi.nl wrote: > I’m getting increasingly worried about the future of Python, That Python will become even more popular? TIOBE: second place, 0.16% below C. PYPL: first place, 12.3% above Java. RedMonk: equal second with Java. https://www.tiobe.com/tiobe-index/ https://pypl.github.io/PYPL.html https://redmonk.com/sogrady/2021/08/05/language-rankings-6-21/ We must be doing something right and maybe the problems that we see are not as big as we fear. Language popularity is not in and of itself important. It doesn't really matter whether Python is 1st or 10th in language popularity. But the CPython part (at least) of the Python language and ecosystem is clearly thriving. Do you have a reason to think that it is in danger in some way? Some factor that didn't apply equally in 2001 and 2011 as it does in 2021? > 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. Admittedly, the yearly release schedule *is* a new policy. I don't remember the rationale for it or who it is supposed to benefit, and I don't know what we are doing to objectively decide whether the change made things better or worse. As for the C-API... Python is 30 years old. Has it ever had a stable C-API before now? Hasn't it *always* been the case that C packages have targetted a single version and need to be rebuilt from source on every release? These are not rhetorical questions, I genuinely do not know. I *think* that there was an attempt to make a stable C API back in 3.2 days: https://www.python.org/dev/peps/pep-0384/ but I don't know what difference it has made to extension writers in practice. From your description, it sounds like perhaps not as big a difference as we would have liked. Maybe extension writers are not using the stable C API? Is that even possible? Please excuse my ignorance. -- Steve ___ 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/GN5QGYZEIFFMSJ66EIYG7H4ZNBIZM7FU/ Code of Conduct: http://python.org/psf/codeofconduct/
