[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.
I don’t see how the stable ABI works as a substitute for vendoring Python. A lot of other things can still vary even when the C API remains the same! (E.g. syntax, and stdlib behavior.) On Thu, Jun 17, 2021 at 11:49 Steve Dower wrote: > On 6/9/2021 2:20 PM, Petr Viktorin wrote: > > On 09. 06. 21 13:09, Paul Moore wrote: > >> Also, I often use the stable ABI when embedding, so that > >> I can replace the Python interpreter without needing to recompile my > >> application and redeploy new binaries everywhere (my use case is > >> pretty niche, though, so I wouldn't like to claim I represent a > >> typical user...). > > > > I hope this use case becomes non-niche. I would love it if embedders > > tell people to just use any Python they have lying around, instead of > > vendoring it (or more realistically, embedding JS or Lua instead). > > I also hope it becomes non-niche, but I'd rather you started > embedding/vendoring CPython rather than using anything that just happens > to be laying around. > > The number one issue that *all* of my customers (and their customers) > have is installation. For most of them, the best way to solve it is to > not make them install Python themselves, which in many cases means > vendoring. The more acceptable and easy we can make this process, the > more Python will be a viable choice against JS or Lua (though with all > the other C API, threading and initialization issues, it's unlikely that > embedding CPython is going to become significantly more attractive than > those two - even IronPython still lives on for embedding because it > works so well). > > Cheers, > 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/36MZXQC3WGDXO6SFTPGT7RC34EMFPP6E/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ 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/3XPVDTAFFLXISFRD62QUFRZI5Q36Y6TN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] [RELEASE] Python 3.10.0b3 is available
Summer is almost here (at least in half of the planet) and Python 3.10 is finishing baking in the oven. For those of you that want to taste it before is finally ready (and if you are a library developer, you certainly do!) you can have the second-to-last beta now, but be careful as is still very hot ;) https://www.python.org/downloads/release/python-3100b3/ #This is a beta preview of Python 3.10 Python 3.10 is still in development. 3.10.0b3 is the third of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.10 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2021-08-02). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.10.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.10 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next pre-release of Python 3.10 will be 3.10.0b4, currently scheduled for Saturday, 2021-07-10. #And now for something completely different There are no green stars. Why? In general, objects don’t emit a single wavelength of light when they shine. Instead, they emit photons in a range of wavelengths. If you were to use some sort of detector that is sensitive to the wavelengths of light emitted by an object, and then plotted the number of them versus wavelength, you get a lopsided plot called a blackbody curve. For an object as hot as the Sun, that curve peaks at blue-green, so it emits most of its photons there. But it still emits some that are bluer, and some that are redder. When we look at the Sun, we see all these colors blended together. Our eyes mix them up to produce one color: white. A warmer star will put out more blue, and a cooler one redder, but no matter what, our eyes just won’t see that as green. Due to how we perceive color, the only way to see a star as being green is for it to be only emitting green light. But as starts always emit radiation following the blackbody curve, that’s pretty much impossible. # We hope you enjoy those new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from very cloudy London, Your friendly release team, Pablo Galindo @pablogsal Ned Deily @nad Steve Dower @steve.dower ___ 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/VNUESN72NYKV5DKM6GJ3WUFUS6DWVUSN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.
On 6/9/2021 2:20 PM, Petr Viktorin wrote: On 09. 06. 21 13:09, Paul Moore wrote: Also, I often use the stable ABI when embedding, so that I can replace the Python interpreter without needing to recompile my application and redeploy new binaries everywhere (my use case is pretty niche, though, so I wouldn't like to claim I represent a typical user...). I hope this use case becomes non-niche. I would love it if embedders tell people to just use any Python they have lying around, instead of vendoring it (or more realistically, embedding JS or Lua instead). I also hope it becomes non-niche, but I'd rather you started embedding/vendoring CPython rather than using anything that just happens to be laying around. The number one issue that *all* of my customers (and their customers) have is installation. For most of them, the best way to solve it is to not make them install Python themselves, which in many cases means vendoring. The more acceptable and easy we can make this process, the more Python will be a viable choice against JS or Lua (though with all the other C API, threading and initialization issues, it's unlikely that embedding CPython is going to become significantly more attractive than those two - even IronPython still lives on for embedding because it works so well). Cheers, 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/36MZXQC3WGDXO6SFTPGT7RC34EMFPP6E/ Code of Conduct: http://python.org/psf/codeofconduct/
