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
>
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
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 "lik
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 no
6 months ago, I wrote a different document based on HPy Manifesto:
"PEP: Taking the Python C API to the Next Level"
https://mail.python.org/archives/list/python-dev@python.org/message/RA7Q4JAUEITJBOUAXFEJKRRM2RR3QSZI/
Victor
On Mon, Apr 4, 2022 at 5:20 PM Petr Viktorin wrote:
>
> On 03. 02. 22
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)
It will likely take multiple iterations (Python releases) to reach
this goal, and incompatible C API changes may
On 4/4/2022 11:19 AM, Petr Viktorin wrote:
On 03. 02. 22 1:40, Guido van Rossum wrote:
[...]
I understand the CPython is stuck supporting the de-facto standard C
API for a long time. But unless we pick a "north star" (as people call
it nowadays) of what we want to support in say 5-10 years, t
On 03. 02. 22 1:40, Guido van Rossum wrote:
[...]
I understand the CPython is stuck supporting the de-facto standard C API
for a long time. But unless we pick a "north star" (as people call it
nowadays) of what we want to support in say 5-10 years, the situation
will never improve.
My point
On Mon, 7 Feb 2022 15:29:39 +0100
Victor Stinner wrote:
> On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote:
> > CPython is also affected by these issues, but the benefits of PEP 674
> > (alone) are too indirect, so I chose to avoid mentioning CPython
> > issues directly, to avoid confusion.
On 07. 02. 22 15:29, Victor Stinner wrote:
On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote:
CPython is also affected by these issues, but the benefits of PEP 674
(alone) are too indirect, so I chose to avoid mentioning CPython
issues directly, to avoid confusion.
A concrete example of pro
On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote:
> CPython is also affected by these issues, but the benefits of PEP 674
> (alone) are too indirect, so I chose to avoid mentioning CPython
> issues directly, to avoid confusion.
A concrete example of problem caused by exposing structures in the
On 07. 02. 22 14:26, Victor Stinner wrote:
On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin wrote:
Basically, instead of "We'll remove this API now because it prevents
moving to a hypothetical moving garbage collector", it should be "Here
is a moving garbage collector that speeds Python up by 30%,
On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin wrote:
> Basically, instead of "We'll remove this API now because it prevents
> moving to a hypothetical moving garbage collector", it should be "Here
> is a moving garbage collector that speeds Python up by 30%, but to add
> it we need to remove these
On 31. 01. 22 16:14, Victor Stinner wrote:
On Mon, Jan 31, 2022 at 4:03 PM Petr Viktorin wrote:
If we change the stable ABI, I would prefer to fix multiple issues at
once. Examples:
* No longer return borrowed references (ex: PyDict_GetItem is part of
the stable ABI) and no longer steal ref
Trying to cut things short, there's one thing I'd like to correct:
On Thu, Feb 3, 2022 at 9:15 AM Victor Stinner wrote:
> [...]
>
> Another example is that Cython currently calls PyCode_New() to create
> a fake frame object with a filename and line number. IMO it's the
> wrong abstraction level:
On Fri, Feb 4, 2022 at 12:52 AM Eric V. Smith wrote:
>
> On 2/3/2022 12:15 PM, Victor Stinner wrote:
> >
> > IMO if PyObject* becomes a handle, the migration to the HPy API should
> > be much easier.
>
> It seems to me that moving PyObject* to be a handle leaves you in a
> place very similar to HP
On Thu, Feb 3, 2022 at 3:53 PM Eric V. Smith wrote:
> On 2/3/2022 12:15 PM, Victor Stinner wrote:
> > I'm working bottom-to-top: prepare PyObject and PyVarObject to become
> > opaque, *and* top-to-bottom: prepare subclasses (structures
> > "inheriting" from PyObject and PyVarObject) to become opa
On Fri, Feb 4, 2022 at 12:55 AM Eric V. Smith wrote:
> It seems to me that moving PyObject* to be a handle leaves you in a
> place very similar to HPy. So why not just focus on making HPy suitable
> for developing C extensions, leave the existing C API alone, and
> eventually abandon the existing
On 2/3/2022 12:15 PM, Victor Stinner wrote:
I'm working bottom-to-top: prepare PyObject and PyVarObject to become
opaque, *and* top-to-bottom: prepare subclasses (structures
"inheriting" from PyObject and PyVarObject) to become opaque like
PyFrameObject.
IMO if PyObject* becomes a handle, the mi
On Wed, Feb 2, 2022 at 4:46 PM Guido van Rossum wrote:
A few notes in this:
> Maybe we need to help there. For example IIRC conda-forge will build conda
> packages -- maybe we should offer a service like that for wheels?
>
Yes, conda-forge used a complex CI system to build binaries conda packa
On Thu, Feb 3, 2022 at 9:27 AM Victor Stinner wrote:
> Hi Guido,
>
[SNIP]
>
> On Thu, Feb 3, 2022 at 1:40 AM Guido van Rossum wrote:
>
>
[SNIP]
> >
> > Maybe we need to help there. For example IIRC conda-forge will build
> conda packages -- maybe we should offer a service like that for whee
Hi Guido,
My "north star", as you say, is the HPy "design" (not the actual HPy
API). I would like to convert PyObject* to opaque handles:
dereferencing a PyObject* pointer would simply fail with a compiler
error.
I'm working bottom-to-top: prepare PyObject and PyVarObject to become
opaque, *and*
I'm sorry, I was overwhelmed and didn't find the time until now to answer
this. A lot was already said about this, so I'll just briefly explain below
(inline).
On Sat, Jan 29, 2022 at 2:38 AM Victor Stinner wrote:
> On Fri, Jan 28, 2022 at 6:28 PM Guido van Rossum wrote:
> > I think we will get
On Mon, Jan 31, 2022 at 4:03 PM Petr Viktorin wrote:
> > If we change the stable ABI, I would prefer to fix multiple issues at
> > once. Examples:
> >
> > * No longer return borrowed references (ex: PyDict_GetItem is part of
> > the stable ABI) and no longer steal references (ex:
> > PyModule_AddO
On 31. 01. 22 15:40, Victor Stinner wrote:
On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin wrote:
(* we could also break the stable ABI, and we could even do it
reasonably safely over a long period of time, but that's a whole
different discussion.)
IMO the stable ABI must be change in the lo
On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin wrote:
> (* we could also break the stable ABI, and we could even do it
> reasonably safely over a long period of time, but that's a whole
> different discussion.)
IMO the stable ABI must be change in the long term, it still leaks too
many implementat
On 28. 01. 22 16:04, Victor Stinner wrote:
Hi,
There is a reason why I'm bothering C extensions maintainers and
Python core developers with my incompatible C API changes since Python
3.8. Let me share my plan with you :-)
In 2009 (Python 3.2), Martin v. Löwis did an amazing job with the PEP
38
On Fri, Jan 28, 2022 at 6:28 PM Guido van Rossum wrote:
> I think we will get *one* chance in the next decade to get it right. Whether
> that's HPy or evolution of the C API I'm not sure.
Would you mind to elaborate? Which risk do you expect from switching
to HPy and from fixing the C API (intro
On 1/28/2022 6:17 PM, Antonio Cuni wrote:
Of course, in order to be fully usable, the HPy universal ABI will need special
support by PyPI/pip/etc, because at the moment it is impossible to package it
inside a wheel, AFAIK.
It's totally possible, it's just that none of the existing tools will
> If a project does R releases per year for P platforms that need to support V
> versions of Python, they would normally have to build R * P * V wheels.
> With a stable ABI, they could reduce that to R * P. That's the key point,
> right?
> Can HPy do that?
actually, it can do even better than tha
> Does HPy have any clear guidance or assistance for their users to keep
> it up to date?
not right now, because we are still somewhat in alpha mode and sometimes we
redesign the API and/or break compatibility. But the plan is of course to
stabilize at some point.
> I think it can be done with
On 1/28/2022 5:15 PM, Barry Warsaw wrote:
On Jan 28, 2022, at 09:00, Steve Dower wrote:
Does HPy have any clear guidance or assistance for their users to keep it up to
date?
I'm concerned that if we simply substitute "support the C API for everyone" with
"support the C API for every version
I think we will get *one* chance in the next decade to get it right.
Whether that's HPy or evolution of the C API I'm not sure.
Victor, am I right that the (some) stable ABI will remain important because
projects don't have resources to build wheels for every Python release? If
a project does R re
On Jan 28, 2022, at 09:00, Steve Dower wrote:
>
> Does HPy have any clear guidance or assistance for their users to keep it up
> to date?
>
> I'm concerned that if we simply substitute "support the C API for everyone"
> with "support the C API for every version of HPy" we're no better off.
Wi
Does HPy have any clear guidance or assistance for their users to keep
it up to date?
I'm concerned that if we simply substitute "support the C API for
everyone" with "support the C API for every version of HPy" we're no
better off.
I think it can be done with clear communication from the HP
Wait, where is the HPy project in that plan? :-) The HPy project
(brand new C API) is a good solution for the long term!
My concerns about HPy right now is that, in short, CPython has to
continue supporting the C API for a few more years, and we cannot
evolve CPython before it will become reasonab
36 matches
Mail list logo
