Hi everyone,
We have a huge amount of buildbots failing and seems to be related to
different issues
that keep piling up. To prevent this from going worse,* I am blocking the
main branch*
*until these issues are resolved.*
Only release managers and the developer in residence will be able to merge
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
> 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
ACTIVITY SUMMARY (2022-01-21 - 2022-01-28)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7157 (-18)
closed 51138 (+124)
total 58295 (+106)
Open issues
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
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
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.
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
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
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
384 "Defining a Stable ABI" to provide a
Steven D'Aprano writes:
> Or maybe, as a developer (not an end-user of an app), you could be more
> proactive in reporting those warnings to the third party, and
> encouraging them to fix them. Maybe even submitting a patch?
As Chris B points out, it's quite possible that (generic) you have
> tl; dr Python no longer leaks memory at exit on the "python -c pass" command
> ;-)
Whooohooo! :D
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
On Thu, Jan 27, 2022 at 10:47 AM Steven D'Aprano
wrote:
> > >Getting the right people to pay attention to them is always the hard
> part.
>
> Or maybe, as a developer (not an end-user of an app), you could be more
> proactive in reporting those warnings to the third party, and
> encouraging them
14 matches
Mail list logo
