[Python-Dev] So many PEPs

Steering Council, g'day, Hawaii? ("copying" BDFL-emeritus, everyone) I'm sorry you haven't heard from me in a while. Actually, neither have any of my other "girl friends" heard from me. I was worried that they might be sad. Then I found out that one of them was at some kind of party at a club or

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

Are you talking about gcc -Wignored-qualifiers? It seems like such warning is only emitted where the function is *defined*, not where the function is *called*. Example: --- const int f(void) { return 1; } int main() { return f(); } --- Output: --- $ gcc -Wextra y.c -o y y.c:1:1: warning: type

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

For me, HPy is the only valid stable API and stable ABI in the long term which is efficient on any Python implementation. Its design is very different than the C API: HPy avoids all C API design mistakes, it doesn't leak any implementation detail. HPy can already be used today on CPython, even if

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 8/12/21 4:36 am, Antoine Pitrou wrote: Is there a way to emit a compilation warning when those macros are used as l-values? Even if only enabled on some compilers. Maybe the macro could be written so that it expands to something with a cast around it? I think gcc has an option for warning

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

Hi Victor, I wonder if there's a role for HPy in this context? What if instead of evolving the stable ABI and the limited API, instead we were to focus on first-class support for HPy? Surely 5 release cycles would be enough to completely remove the stable ABI and perhaps even the limited API in

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

An idea for unmaintained incompatible C extensions is to update the C code when a C extension is installed, as part of the build process. For example, replace "Py_TYPE(obj) = new_type" with "Py_SET_TYPE(obj, new_type)". Something similar to the old "2to3" option of setuptools. The

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

Extract of the Backward Compatibility section of the PEP: "This change does not follow the PEP 387 deprecation process. There is no known way to emit a deprecation warning only when a macro is used as a l-value, but not when it's used differently (ex: as a r-value)." Victor On Tue, Dec 7, 2021

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On Tue, Dec 7, 2021 at 3:43 PM Petr Viktorin wrote: > If we would deprecate using Py_REFCNT as l-value in the docs, but wait > with the conversion until it was *actually* needed, we would not lose > anything: > (...) > ## CPython nogil fork > > In CPython, we cannot change structs that are part

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On Tue, Dec 7, 2021 at 1:09 PM Steve Dower wrote: > On 12/7/2021 6:52 PM, Sebastian Berg wrote: > > One thing we once did in NumPy (for a runtime problem), was to > > intentionally break everyone at pre-release/dev time to point out what > > code needed fixing. Then flip the switch back at

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 12/7/2021 6:52 PM, Sebastian Berg wrote: One thing we once did in NumPy (for a runtime problem), was to intentionally break everyone at pre-release/dev time to point out what code needed fixing. Then flip the switch back at release time as to not break production. After a long enough time we

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On Tue, Dec 7, 2021 at 11:02 AM Christian Heimes wrote: > On 07/12/2021 19.28, Guido van Rossum wrote: > > I assume it would be insensitive to ask whether we could just get rid of > > the stable ABI altogether and focus on the limited API? Just tell > > everyone they have to rebuild binary

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On Tue, Dec 7, 2021 at 9:00 AM Joao S. O. Bueno wrote: > Sorry for stepping in - but I am seeing too many arguments in favour > of the rules because "they are the rules", and just Victor arguing with > what is met in the "real world". > > But if this update can be done by a simple search/replace

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 07/12/2021 19.28, Guido van Rossum wrote: I assume it would be insensitive to ask whether we could just get rid of the stable ABI altogether and focus on the limited API? Just tell everyone they have to rebuild binary wheels for every Python feature release. Presumably the deprecation of

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On Tue, 2021-12-07 at 13:54 -0300, Joao S. O. Bueno wrote: > Sorry for stepping in - but I am seeing too many arguments in favour > of the rules because "they are the rules", and just Victor arguing > with > what is met in the "real world". > > But if this update can be done by a simple

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On Tue, Dec 7, 2021 at 12:58 AM Petr Viktorin wrote: > On 06. 12. 21 21:50, Guido van Rossum wrote: > > On Mon, Dec 6, 2021 at 12:12 PM Petr Viktorin > > wrote: > > > > On 06. 12. 21 20:29, Guido van Rossum wrote: > > > Hi Petr, > > > > > > In PEP

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

Sorry for stepping in - but I am seeing too many arguments in favour of the rules because "they are the rules", and just Victor arguing with what is met in the "real world". But if this update can be done by a simple search/replace on the C source of projects, I can only perceive two scenarios

[Python-Dev] Re: PEP 669: Low Impact Monitoring for CPython

Interesting! Some remarks about the proposed API. On Tue, Dec 7, 2021 at 4:58 PM Mark Shannon wrote: > There is no change to the language and it adds 7 functions to the sys module, > so shouldn't be too intrusive for those of who aren't planning on > implementing any of those tools. Where are

[Python-Dev] PEP 669: Low Impact Monitoring for CPython

Hi, I would like to announce latest PEP, PEP 669: Low Impact Monitoring for CPython. The aim of this PEP is to provide an API for profilers, debuggers and other tools to avoid the punitive overhead of using sys.settrace. If you have any interest in profilers, debuggers, coverage tools or

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On Tue, 7 Dec 2021 15:39:25 +0100 Petr Viktorin wrote: > On 30. 11. 21 19:52, Victor Stinner wrote: > > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote: > >> How about *not* asking for an exception and just following the PEP 387 > >> process? Is that really too burdensome? > > > >

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 30. 11. 21 19:52, Victor Stinner wrote: On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote: How about *not* asking for an exception and just following the PEP 387 process? Is that really too burdensome? The Backward Compatibility section gives an explanation: "This change does not

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 06. 12. 21 21:50, Guido van Rossum wrote: On Mon, Dec 6, 2021 at 12:12 PM Petr Viktorin > wrote: On 06. 12. 21 20:29, Guido van Rossum wrote: > Hi Petr, > > In PEP 384 it is written that no functions starting with an underscore > are part