[Python-Dev] Re: PEP 587

Hi Zak, and welcome! This list is for discussing the current and future development of the CPython interpreter, not a general help-desk for Python beginners. When you signed up to this email list, the signup page says: Do not post general Python questions to this list. For help with Py

[Python-Dev] Re: PEP 587

This mailing list is for discussing making _of_ Python, not _with_ it. You are better to ask this over on python-list. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.or

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

This is too-little, too-late (I was offline this past week), but for those who enjoy digging through historical archives, the Tcl folks had an interesting stubs mechanism that was *supposed* to solve the versioning issue (although I suspect it hasn’t actually done much in that regard) in additio

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

> On 1 Oct 2019, at 10:55, Thomas Wouters wrote: > > > > On Mon, Sep 30, 2019 at 11:00 PM Brett Cannon > wrote: > Victor Stinner wrote: > > Hi Nick, > > Le dim. 29 sept. 2019 à 08:47, Nick Coghlan ncogh...@gmail.com > > a écrit : > > > I

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Mon, Sep 30, 2019 at 11:00 PM Brett Cannon wrote: > Victor Stinner wrote: > > Hi Nick, > > Le dim. 29 sept. 2019 à 08:47, Nick Coghlan ncogh...@gmail.com a écrit : > > > I don't quite understand the purpose of this change, > > > as there's no > > > stable ABI for applications embedding CPython

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Sorry for the bad timing. I dislike working under pressure. The discussion on python-dev, the bug tracker and pull requests was really interesting. The issue has been fixed: the whole idea of stable ABI for PyConfig has been abandoned. If you want to switch to a different version of Python when yo

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 30Sep2019 1625, Nick Coghlan wrote: After merging your PR and closing mine, I had an idea for Python 3.9: what if we offered a separate public "int Py_CheckVersionCompatibility(uint64_t header_version)" call? (64 bit input rather than 32 to allow for possible future changes to the version n

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Tue., 1 Oct. 2019, 8:38 am Nick Coghlan, wrote: > Later, if we decide to start proving a stable ABI for embedded Python, >> we can still add a "version" or "struct_size" field to PyConfig later >> (for example in Python 3.9). >> > > Thanks Victor, I think this is the right way for us to go, gi

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Tue., 1 Oct. 2019, 6:47 am Victor Stinner, wrote: > Hi back, > > It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not > really liked". > > I don't see any traction to provide a stable ABI for embedded Python. > The consensus is more towards: "it doesn't work and we don't want

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Le lun. 30 sept. 2019 à 23:26, Antoine Pitrou a écrit : > I think if you wanted to make the PyConfig apt at providing > ABI-stability, you should have designed it differently. > `PyType_FromSpec` provides a useful model (pass an arbitrary-sized > static array of field initializers). PyConfig is e

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Mon, 30 Sep 2019 22:43:40 +0200 Victor Stinner wrote: > Hi back, > > It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not > really liked". > > I don't see any traction to provide a stable ABI for embedded Python. Not at the last minute in a rc1, I'd say :-) I think if you w

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Victor Stinner wrote: > Hi Nick, > Le dim. 29 sept. 2019 à 08:47, Nick Coghlan ncogh...@gmail.com a écrit : > > I don't quite understand the purpose of this change, > > as there's no > > stable ABI for applications embedding CPython. > > Well, I would like to prepare Python to provide a stable ABI

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Hi back, It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not really liked". I don't see any traction to provide a stable ABI for embedded Python. The consensus is more towards: "it doesn't work and we don't want to bother with false promises" (nor add code for that). Since Luka

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Mon., 30 Sep. 2019, 7:43 pm Petr Viktorin, wrote: > On 2019-09-30 00:33, Nick Coghlan wrote: > [...] > > We'll never change the size of the config structs (or any other public > > struct) in a maintenance branch > > But we *will* change it in alphas/betas, and then we will ask people to > try

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Tue., 1 Oct. 2019, 3:05 am Nick Coghlan, wrote: > > The only outcome I'd consider undesirable is shipping a public API > that's more awkward to use than it needs to be, doesn't conform to the > accepted version of the PEP, and doesn't protect against most of the > potential sources of segfault

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Mon, 30 Sep 2019 at 23:50, Victor Stinner wrote: > > Le lun. 30 sept. 2019 à 13:45, Nick Coghlan a écrit : > > > I understand that your main motivation to use the Python version > > > number rather than sizeof(PyConfig) is the error message. > > > > No, my main motivation is to create an API t

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

I agree that passing a struct size as struct member values sounds a bit unidiomatic. Also, it doesn't achieve ABI stability, just allows erroring out in case the user links with the wrong Python version. Regards Antoine. On Sun, 29 Sep 2019 16:47:41 +1000 Nick Coghlan wrote: > On Sat, 28 Se

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Le lun. 30 sept. 2019 à 13:45, Nick Coghlan a écrit : > > I understand that your main motivation to use the Python version > > number rather than sizeof(PyConfig) is the error message. > > No, my main motivation is to create an API that can emit a useful > error message on *ALL* version conflicts

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Mon, 30 Sep 2019 at 09:37, Victor Stinner wrote: > > Le lun. 30 sept. 2019 à 00:33, Nick Coghlan a écrit : > > As noted above, despite what I wrote on BPO, you no longer need to persuade > > me that the version check is desirable, only that a narrow check on > > specific struct sizes is pref

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 2019-09-30 00:33, Nick Coghlan wrote: [...] We'll never change the size of the config structs (or any other public struct) in a maintenance branch But we *will* change it in alphas/betas, and then we will ask people to try their software out with these. Of course, there are no actual API/AB

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 9/29/2019 5:13 PM, Victor Stinner wrote: It seems simpler to me to pass the structure size rather than the Python version. It avoids the risk of updating the structure without update the Python version. I also avoids to have to change the Python version immediately when PyConfig is modified.

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Le lun. 30 sept. 2019 à 00:33, Nick Coghlan a écrit : > As noted above, despite what I wrote on BPO, you no longer need to persuade > me that the version check is desirable, only that a narrow check on specific > struct sizes is preferable to a broad check on the expected API version. I underst

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Mon., 30 Sep. 2019, 7:13 am Victor Stinner, wrote: > Hi Nick, > > Le dim. 29 sept. 2019 à 08:47, Nick Coghlan a écrit : > > I don't quite understand the purpose of this change, as there's no > > stable ABI for applications embedding CPython. > > Well, I would like to prepare Python to provide

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

Hi Nick, Le dim. 29 sept. 2019 à 08:47, Nick Coghlan a écrit : > I don't quite understand the purpose of this change, as there's no > stable ABI for applications embedding CPython. Well, I would like to prepare Python to provide a stable ABI for embedded Python. While it's not a design goal yet

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On Sat, 28 Sep 2019 at 12:56, Victor Stinner wrote: > > Hi, > > I dislike having to do that, but I had to make a last minute change in > my PEP 587 "Python Initialization Configuration" to allow to modify > the structure in the future without breaking the backward > compatibility. I added a "struc