This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author erlendaasland
Recipients erlendaasland, pablogsal, petr.viktorin, rhettinger, shihai1991
Date 2021-10-22.16:58:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> My understanding is that this entire class of code changes has been put on hold pending Steering Council approval.

Can you please point me to the official SC statement regarding this? I cannot find it.

> It represents a great deal of code churn and creation on new APIs.

You cannot implement [the accepted] PEP 630 without a little bit of code churn ;) Luckily, (most of) the APIs needed are defined in PEP 573 (also accepted, now in final state).

> Several of the patches had had negative performance impacts [...]

Can you provide a list of the patches/bpo's with still unresolved performance impacts?

> [...] all of the patches have made the code more complicated and harder to maintain

I have not seen other complaints about this? Can you provide a link to a bpo or a Discourse topic? If you find the new APIs hard to use or understand, we can of course improve the documentation and the dev guide :)

> Several that I looked at had no tests at all [...]

Actually, we've added tests to heap types with Py_TPFLAGS_IMMUTABLE_TYPE and Py_TPFLAGS_DISALLOW_INSTANTIATION. Apart from that; if a type lives on the stack or on the heap should be transparent for the user, right? The existing test suite will help verify exactly that.

> [...] so there was no discernible or provabler user benefit.

The benefits are described in PEP 630 ;)

> IIRC one or more of the patches created new bugs, were destabilizing, or altered the APIs in subtle ways.

There has been cases with ref-leaks, but that happens from time to time in all types of PRs, not just heap type PRs. Those have all been caught and fixed, thanks to reviewers and ref-leak-bots.

I'm not sure what you mean with 'destabilizing'? Can you point to a specific example or issue?

Regarding APIs, there was a long discussion about immutability and disallowing instantiation during the 3.10 beta period. Those issues were fixed and unblocked.

> Please get explicit approval from the SC before continuing to sweep through the code base, creating heap types everywhere.

Strictly speaking, the fact that PEP 630 is accepted and active _is_ an explicit approval. It has not been withdrawn or rejected.

> Given that some essential third party modules are not going down this path [...]

Which ones? Can you provide a link?

> [...] it is unlikely that general users would ever see any benefit.

The benefits are explained in PEP 630. It is a well written PEP; I suggest you re-read it :)
Date User Action Args
2021-10-22 16:58:50erlendaaslandsetrecipients: + erlendaasland, rhettinger, petr.viktorin, pablogsal, shihai1991
2021-10-22 16:58:50erlendaaslandsetmessageid: <>
2021-10-22 16:58:50erlendaaslandlinkissue45113 messages
2021-10-22 16:58:50erlendaaslandcreate