[Python-Dev] Re: Need help on security vulnerability zlib 1.2.11
The pyinstaller docs https://pyinstaller.org/en/stable/ refer to the google group pyinstal...@googlegroups.com or you can try their issue tracker https://github.com/pyinstaller/pyinstaller/issues ___ 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/HUYWJCJAGM2PBVYYTUUDSHHLGMW6P6WC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone
On Tue, 5 Apr 2022 22:54:00 +0200 Victor Stinner wrote: > IMO it would be better to keep the HPy design as the long term goal: > > * Refer to Python objects with opaque handles > * All structures are opaque (with a few exceptions, like PyType_Spec) If the HPy design is the long term goal, why not just recommend that people use HPy? And keep the C API for expert users with specific needs that are not accomodated by HPy. To me, it seems that trying to change the C API to be "like HPy" is creating a lot of work, churn and pain for little gain. (and, yes, perhaps HPy needs to be funded or supported by the PSF if it doesn't advance fast enough) Regards Antoine. > > It will likely take multiple iterations (Python releases) to reach > this goal, and incompatible C API changes may need a PEP (like PEP > 674), but IMO it's good to keep this goal in mind. > > Otherwise, it's not easy to understand the rationale for changes like > https://peps.python.org/pep-0674/ "PEP 674 – Disallow using macros as > l-values". > > Victor ___ 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/VMSSS46YWQTJYYSPZVCJXNUPY4L5YSIT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Updating inspect APIs
On Sun, 17 Apr 2022 19:00:45 -0700 Guido van Rossum wrote: > Is it not acceptable to create new functions that return non-named-tuple > objects (e.g. dataclasses with slots)? I'd advocate creating a single new function that provides more structured access to that various information, like we did with `inspect.signature()`. We also don't have to formally deprecate the older APIs, just recommend the new one in the docs. Regards Antoine. > Otherwise the way the stats result > tuple works is a reasonable approach (and possibly deprecate indexed > access?) > > On Sun, Apr 17, 2022 at 10:23 AM Pablo Galindo Salgado > wrote: > > > Hi, > > > > We are currently debating in gh-88116 ( > > https://github.com/python/cpython/issues/88116) > > what's the best way forward to update the APIs in the inspect module to > > include the new position information. > > > > These APIs are inspect.getframeinfo, inspect.getouterframes, > > inspect.getinnerframes, inspect.stack and inspect.trace. > > > > The problem is that these APIs return a named tuple that now needs to > > include several new attributes (or one 4 tuple for > > the positions). Being named tuples, if we add a new attribute, existing > > unpackings of the tuple will now fail because there > > are more elements or the elements are in different positions. Also, it > > will be quite weird to add the new attributes at the > > end but leave the line number at the beginning. > > > > What's the best way to proceed here? The suggested way is to create a > > namedtuple subclass that adds the extra attributes > > but doesn't allow indexed access to it (there is a precedent to this in > > how we handled updating os.stat_result). I personally > > find this quite confusing but it certainly works. There may be other > > options. > > > > What do you think? > > > > Cheers from sunny London, > > Pablo Galindo Salgado > > ___ > > 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/RTGG637WWPOWUHUF6TRJYUSBYYSVUPRA/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > ___ 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/FNEUYHG6O7XM6N5NQMNXG7IL2PCEYIEI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone
On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote: > If the HPy design is the long term goal, why not just recommend that > people use HPy? And keep the C API for expert users with specific > needs that are not accomodated by HPy. > > To me, it seems that trying to change the C API to be "like HPy" is > creating a lot of work, churn and pain for little gain. If you put HPy aside, "Fixing" the C API has multiple advantages for CPython and its (C API) users. For consumers of the C API (C extensions, Cython, pybind11, etc.), once most implementation details will be hidden, the C API will become way more stable. The "C API > Porting to Python x.y" section of What's New in Python x.y should become way shorter. Or at least, the number of impacted C extensions should be way smaller. Sadly, fixing the C API to hide implementation details requires to adapt (modify) C extensions. Even if usually only a few lines should be changed, and the pythoncapi-compat project now automates most of these changes. For CPython, no longer leaking implementation details allow to change "any implementation detail" without getting a heavy and annoying backfire from grumpy users should be very comfortable. In Python 3.9, 3.10 and 3.11 development cycles, we got backfire multiple times, and each time, it was really unpleasant both for CPython core devs and for C extensions maintainers (both have legit concerns and use cases). While these changes should ease the migration to HPy, it's not my goal. HPy requires to add a "ctx" parameter, it's a different API (there are multiple subtle differences). > (and, yes, perhaps HPy needs to be funded or supported by the PSF if it > doesn't advance fast enough) What can be done in practice for that? If I understood correctly, Oracle is sponsoring the project since they want to use HPy for GraalPython (of their GraalVM). Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/PB7BG7W76BQXP3KS3C6XT5GOFJS24LZB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone
On Wed, 20 Apr 2022 12:52:53 +0200 Victor Stinner wrote: > On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote: > > If the HPy design is the long term goal, why not just recommend that > > people use HPy? And keep the C API for expert users with specific > > needs that are not accomodated by HPy. > > > > To me, it seems that trying to change the C API to be "like HPy" is > > creating a lot of work, churn and pain for little gain. > > If you put HPy aside, "Fixing" the C API has multiple advantages for > CPython and its (C API) users. With the caveat that the "fixing" probably requires users to fix their packages as well. > For consumers of the C API (C extensions, Cython, pybind11, etc.), > once most implementation details will be hidden, the C API will become > way more stable. The *API* is quite stable already if you don't use the private/internal functions. Perhaps you're thinking about the ABI? > > (and, yes, perhaps HPy needs to be funded or supported by the PSF if it > > doesn't advance fast enough) > > What can be done in practice for that? If I understood correctly, > Oracle is sponsoring the project since they want to use HPy for > GraalPython (of their GraalVM). Also, Anaconda recently hired Antonio Cuni, hopefully giving him sufficient time to work on HPy. So perhaps nothing needs to be done in practice. Regards Antoine. ___ 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/QKWLX5223UD2ZCDYJLRDEXISFVFYWU7P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone
On Wed, Apr 20, 2022 at 1:44 PM Antoine Pitrou wrote: > > For consumers of the C API (C extensions, Cython, pybind11, etc.), > > once most implementation details will be hidden, the C API will become > > way more stable. > > The *API* is quite stable already if you don't use the private/internal > functions. Perhaps you're thinking about the ABI? In Fedora, we update Python early during Python alpha versions, and sadly it's common that many C extensions are incompatible (need to be modified) at each 3.x release. A single minor incompatible change is enough to require changing a C extension. I believe that once the C API will leak less implementation details, changing Python will impact less C extensions. HPy API looks more stable by design: it's way smaller and only expose the bare minimum. I took notes on (Python and C API) incompatible changes, impacting most Python projects and C extensions, from Python 3.7 to Python 3.11: https://github.com/vstinner/vstinner.github.io/blob/pelican/draft/python-incompatible-changes.rst "C API > Porting to Python 3.11" section is quite long, PyFrameObject and PyThreadState structures changed a lot (PyFrameObject moved to the internal C API): https://docs.python.org/dev/whatsnew/3.11.html#id6 "C API > Porting to Python 3.10": https://docs.python.org/dev/whatsnew/3.10.html#id2 "C API > Porting to Python 3.9": https://docs.python.org/dev/whatsnew/3.9.html#id2 "Porting to Python 3.8 > Changes in C API": https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/M6MINEKX7XVQ72IVI3D4XTP2O2J5LD3F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API
Here's the issue with the plan (including Nick's suggestions): https://github.com/python/cpython/issues/91744 On Sun, Apr 10, 2022 at 5:43 AM Nick Coghlan wrote: > > On Thu, 7 Apr 2022, 8:02 pm Petr Viktorin, wrote: >> >> So here's my proposal: >> >> - This API stays with the regular public API (Include/cpython/), but to >> use it you'll need to #define Py_USING_UNSTABLE_API (name up for >> bikeshedding). > > > I'm fine with the rest of what you suggest, but I don't think this is the > right mechanical approach: > > * "unstable" is the wrong term. We already have an unstable API tier: the > internal API, which can change even in maintenance releases. The value of the > new tier is that it is "semi stable": stable in maintenance releases, > unstable in feature releases. > * the lesson I take from our stable ABI experience is that mixing two tiers > of the API in a single header file is hard to maintain, as it's too easy to > add a new API to the wrong section. A separate file that gets included > automatically from the relevant header file(s) when the new definition is > used makes the split much clearer. > > Cheers, > Nick. > > >> >> ___ 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/TGQN7HOPLAV6FDVXGLBTXOXSAQ75XM2S/ Code of Conduct: http://python.org/psf/codeofconduct/
