On Mon, Jan 31, 2022 at 3:57 PM Petr Viktorin wrote:
> Remove the point from the Abstract?
> (...)
> I think you should make it clear that the percentage was taken after
> fixing many of the projects.
Thanks for your review.
I pushed a change to take your remarks in account:
https://github.com/p
On 31. 01. 22 15:30, Victor Stinner wrote:
On Mon, Jan 31, 2022 at 2:31 PM Petr Viktorin wrote:
PEP: 674
Title: Disallow using macros as l-value
The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros
as l-values", which is misleading: it proposes to change 65 macros.
Right,
On Mon, Jan 31, 2022 at 2:31 PM Petr Viktorin wrote:
> > PEP: 674
> > Title: Disallow using macros as l-value
>
> The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros
> as l-values", which is misleading: it proposes to change 65 macros.
Right, I made changes since I posted the
On 18. 01. 22 9:30, Victor Stinner wrote:
Hi,
I made the following changes to the PEP since the version 1 (November 30):
* Elaborate the HPy section and add a new "Relationship with the HPy
project" section
* Elaborate which projects are impacted and which changes are needed
* Remove the PyPy s
On Thu, Jan 27, 2022 at 1:14 AM Larry Hastings wrote:
> Just so I understand: is this effectively permanent? My first thought was,
> we get SWIG to change its code generation, and in a couple of years we can
> follow up and make this change. But perhaps there's so much SWIG code out
> there a
On 1/26/22 3:02 PM, Victor Stinner wrote:
Hi,
My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME()
macros. This change breaks M2Crypto and mecab-python3 projects in code
generated by SWIG. I tried two solutions to prevent SWIG accessing
PyDescrObject members directly:
https://bugs.pyt
Hi,
My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME()
macros. This change breaks M2Crypto and mecab-python3 projects in code
generated by SWIG. I tried two solutions to prevent SWIG accessing
PyDescrObject members directly:
https://bugs.python.org/issue46538
At the end, IMO it's too
Hi,
The HPy project is great and I'm supporting this cool project! As I
wrote, IMO it's the best solution for the long term.
My first concern is that right now, HPy is not mature nor widely used,
and CPython still has to continue supporting a large amount of C
extensions which are not likely to b
On Tue, Dec 7, 2021 at 7:55 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 lo
, 8 December 2021, 18:21
To: python-dev@python.org
Subject: [External] : [Python-Dev] Re: PEP 674: Disallow using macros as l-value
Hi,
On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum wrote:
> I wonder if there's a role for HPy in this context? What if instead of
> evolving the sta
Hi,
On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum wrote:
> 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?
The hope with the HPy project is indeed to provide a C
Hi,
On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum wrote:
> 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?
The hope with the HPy project is indeed to provide a C
On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum gu...@python.org wrote:
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?
The hope with the HPy project is inde
Victor Stinner wrote:
> First, PyPy tried to only implement a subset of the C API and promote
> cffi for incompatible C extensions. This approach failed.
Just to be clear: I don't think any of the PyPy devs assumed the huge Python
c-extension ecosystem would suddenly run to adopt CFFI, so calling
On 07. 12. 21 17:54, 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".
OTOH, coming up with rules and then blatantly ignoring them is silly at
bes
On 08. 12. 21 1:47, Victor Stinner wrote:
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
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 qual
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
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 ab
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 fa
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
upgrade_pythonca
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 a
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 of
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 relea
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
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
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 search/rep
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 thi
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?
> >
> > T
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 fo
On Tue, Nov 30, 2021 at 7:52 PM Victor Stinner wrote:
> For this specific PEP changes, I consider that the number of impacted
> projects is low enough to skip a deprecation process: only 4 projects
> are known to be impacted. One year ago (Python 3.10), 16 were
> impacted, and 12 have already been
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 follow the PEP 387 deprecation process. There
How about *not* asking for an exception and just following the PEP 387
process? Is that really too burdensome?
On Tue, Nov 30, 2021 at 10:30 AM Victor Stinner wrote:
> Hi,
>
> I propose to disallow using macros as l-value. Read and comment the
> plain text below, or read the PEP 674 online,
> h
33 matches
Mail list logo
