Hi,
I'm afraid we are talking past each other. In my case, the applications
are either part of my Python-based work setup, which needs to be rebuilt
anyway in the very infrequent occurrence of a major Python upgrade (I
could get away with using the system python for that on a "stable" distro).
On June 22, 2021 11:18:46 AM GMT+02:00, Henk-Jaap Wagenaar
wrote:
>On Tue, 22 Jun 2021 at 10:06, Petr Viktorin wrote:
>
>> On 21. 06. 21 20:20, Guido van Rossum wrote:
>> > Okay, I think your evidence can then be discounted. Really, any app
>that
>> > relies on the publicly installed Python
On Tue, 22 Jun 2021 at 10:06, Petr Viktorin wrote:
> On 21. 06. 21 20:20, Guido van Rossum wrote:
> > Okay, I think your evidence can then be discounted. Really, any app that
> > relies on the publicly installed Python runs a serious risk of breaking
> > when that Python gets updated, regardless
On 21. 06. 21 20:20, Guido van Rossum wrote:
Okay, I think your evidence can then be discounted. Really, any app that
relies on the publicly installed Python runs a serious risk of breaking
when that Python gets updated, regardless of whether the ABI changes or not.
Unfortunately, this
Okay, I think your evidence can then be discounted. Really, any app that
relies on the publicly installed Python runs a serious risk of breaking
when that Python gets updated, regardless of whether the ABI changes or not.
On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello <
Hi,
Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> Can you elaborate on that use case? Which two applications are you
> thinking of, and what was your goal in driving them? This sounds
> interesting but I haven’t encountered this myself.
Well, I'm not sure the case I was thinking of is
Can you elaborate on that use case? Which two applications are you thinking
of, and what was your goal in driving them? This sounds interesting but I
haven’t encountered this myself.
On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:
> Le 18/06/2021 à
Le 18/06/2021 à 08:50, Paul Moore a écrit :
>
> IMO it doesn't. However for certain applications (the sort of thing I
> was referring to) - where the user is writing their own scripts and
> the embedding API is used merely to expose an interface to the Python
> language, dynamically linking to
On Fri, 18 Jun 2021 at 01:57, Guido van Rossum wrote:
>
> 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.)
IMO it doesn't. However for certain
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.
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,
> On 9 Jun 2021, at 12:28, Inada Naoki wrote:
>
> I think stable ABI keeps symbols, signatures, and memory layouts.
> I don't think stable ABI keeps all behaviors.
As often “it depends”. Behaviour is IMHO part of the API/ABI contract. That
said, that does not necessarily mean that we
On 09. 06. 21 13:09, Paul Moore wrote:
On Wed, 9 Jun 2021 at 11:36, Inada Naoki wrote:
If I am wrong, can we stop keeping stable ABI at Python 3.12?
Python 4.0 won't come in foreseeable future. Stable ABI blocks Python evolution.
Conversely, the stable ABI allows projects to build
On Wed, 9 Jun 2021 at 11:36, Inada Naoki wrote:
> If I am wrong, can we stop keeping stable ABI at Python 3.12?
> Python 4.0 won't come in foreseeable future. Stable ABI blocks Python
> evolution.
Conversely, the stable ABI allows projects to build cross-version
binary wheels. Not many projects
I think stable ABI keeps symbols, signatures, and memory layouts.
I don't think stable ABI keeps all behaviors.
For example, Py_CompileString() is stable ABI.
When we add `async` keyword, Py_CompileString() starts raising an
Error for source code using `async` name.
Is it ABI change? I don't
> On 9 Jun 2021, at 11:13, Victor Stinner wrote:
>
> On Wed, Jun 9, 2021 at 10:32 AM Ronald Oussoren via Python-Dev
> wrote:
>> Its a bit late to complain (and I’m not affected by this myself), but those
>> functions are part of the stable ABI. The change in 3.10 will break any
>>
On Wed, Jun 9, 2021 at 10:32 AM Ronald Oussoren via Python-Dev
wrote:
> Its a bit late to complain (and I’m not affected by this myself), but those
> functions are part of the stable ABI. The change in 3.10 will break any
> extensions that use the stable ABI, use these functions and don’t use
> On 7 Jun 2021, at 05:05, Inada Naoki wrote:
>
> Hi, folks,
>
> Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted
> DeprecationWarning when
> '#' format is used without PY_SSIZE_T_CLEAN defined.
> In Python 3.10, they raise a RuntimeError, not a warning. Extension
>
On Tue, Jun 8, 2021 at 6:02 PM Petr Viktorin wrote:
>
>
> > * Make function PyArg_Parse always raising an exception.
>
> This would break extensions that use the stable ABI.
> (Yes, even starting to raise RuntimeError in 3.10 broke things. And yes,
> it's not strictly an ABI issue, but it has the
On 08. 06. 21 10:05, Serhiy Storchaka wrote:
07.06.21 08:41, Hai Shi пише:
There have an another question. There have many C API defined under
PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT().
Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory?
We should support
07.06.21 08:41, Hai Shi пише:
> There have an another question. There have many C API defined under
> PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT().
> Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory?
We should support binary compatibility to some degree, so there
On Tue, Jun 8, 2021 at 12:53 AM Hai Shi wrote:
>
> > So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
> > Extension modules can use '#' format with ssize_t, without
> > PY_SSIZE_T_CLEAN defined.
> > Or should we wait one more version?
>
> Hi, Inada,
> I suggest we should wait
On Mon, Jun 7, 2021 at 4:52 PM Serhiy Storchaka wrote:
>
> Many users still use 3.6 or 3.7. Jumping from 3.7 to 3.11 could break
> extensions in bad way (crash, truncated data, leaked sensitive
> information, execution of arbitrary code). Also, deprecation warnings in
> 3.8 and 3.9 can be easily
> So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
> Extension modules can use '#' format with ssize_t, without
> PY_SSIZE_T_CLEAN defined.
> Or should we wait one more version?
Hi, Inada,
I suggest we should wait until at least Python 3.12 or Python 4.0.
There have an another
07.06.21 06:05, Inada Naoki пише:
> Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted
> DeprecationWarning when
> '#' format is used without PY_SSIZE_T_CLEAN defined.
> In Python 3.10, they raise a RuntimeError, not a warning. Extension
> modules can not use '#' format with
25 matches
Mail list logo
