I'm a major consumer of these APIs as part of some commercial projects (unfortunately I can't discuss too much further) but we find it worth the effort of keeping up with CPython internal changes to continue using them. Option D seems like the best option from my point of view; any user would need to be able to keep up with bytecode changes already so I think backwards compatibility isn't really a concern.
Unless you feel it's extremely important to follow PEP 387 (slippery slope?), I'd just say "to hell with it". Also, at least if it segfaults, people who haven't updated their code will know very quickly, whereas some other options might cause subtler bugs. On 13/08/2021 18:24, Guido van Rossum wrote: > In 3.11 we're changing a lot of details about code objects. Part of this is > the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine > Grained Error Locations in Tracebacks). > > As a result, the set of fields of the code object is changing. This is fine, > the structure is part of the internal API anyway. > > But there's a problem with two public API functions, PyCode_New() and > PyCode_NewWithPosArgs(). As we have them in the main (3.11) branch, their > signatures are incompatible with previous versions, and they have to be since > the set of values needed to create a code object is different. (The > types.CodeType constructor signature is also changed, and so is its replace() > method, but these aren't part of any stable API). > > Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the PEP > 387 stable ABI. What should we do? > > A. We could deprecate them, keep (restore) their old signatures, and create > crippled code objects (no exception table, no endline/column tables, qualname > defaults to name). > > B. We could deprecate them, restore the old signatures, and always raise an > error when they are called. > > C. We could just delete them. > > D. We could keep them, with modified signatures, and to heck with ABI > compatibility for these two. > > E. We could get rid of PyCode_NewWithPosArgs(), update PyCode() to add the > posonlyargcount (which is the only difference between the two), and d*mn the > torpedoes. > > F. Like (E), but keep PyCode_NewWithPosArgs() as an alias for PyCode_New() > (and deprecate it). > > If these weren't part of the stable ABI, I'd choose (E). But because they > are, I think only (A) or (B) are our options. The problem with (C) is that if > there's code that links to them but doesn't call them (except in some corner > case that the user can avoid), the code won't link even though it would work > fine. The problem with (D) is that if it *is* called by code expecting the > old signature it will segfault. I'm not keen on (A) since it can cause broken > code objects when used to copy a code object with some modified metadata > (e.g. a different filename), since there's no way to pass the exception table > (and several other fields, but the exception table is an integral part of the > code now). > > Code wanting to make slight modifications to code objects such as changing > co_name or co_filename should switch to the .replace() API, which is much > better at this (though calling it from C is a pain, it's possible). Code > wanting to synthesize code should be updated for each release; we should > probably require such code to be built with the internal API and use > _PyCode_New(), which takes a struct argument containing all the necessary > fields. > > Thoughts? I'm especially interested in Petr's opinion given that this is a > case where we'd like to deprecate something in the stable ABI. > > See also discussion in https://bugs.python.org/issue40222 > <https://bugs.python.org/issue40222> (esp. near the end). > > -- > --Guido van Rossum (python.org/~guido <http://python.org/~guido>) > /Pronouns: he/him //(why is my pronoun here?)/ > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NLGBBH6ZPW6O5K2MAUIXEGKLYCAU6NHK/ Code of Conduct: http://python.org/psf/codeofconduct/
