Erlend E. Aasland <erlend.aasl...@innova.no> added the comment:
> 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 :) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45113> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
