Here's the issue with the plan (including Nick's suggestions):
https://github.com/python/cpython/issues/91744
On Sun, Apr 10, 2022 at 5:43 AM Nick Coghlan wrote:
>
> On Thu, 7 Apr 2022, 8:02 pm Petr Viktorin, wrote:
>>
>> So here's my proposal:
>>
>> - This API stays with the regular public API
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 Sun, 17 Apr 2022 19:00:45 -0700
Guido van Rossum wrote:
> Is it not acceptable to create new functions that return non-named-tuple
> objects (e.g. dataclasses with slots)?
I'd advocate creating a single new function that provides more
structured access to that various information, like we did
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
The pyinstaller docs https://pyinstaller.org/en/stable/ refer to the google
group pyinstal...@googlegroups.com or you can try their issue tracker
https://github.com/pyinstaller/pyinstaller/issues
___
Python-Dev mailing list -- python-dev@python.org
To
