[Python-Dev] Handling deprecations in the face of PEP 384 (original) (raw)

Brett Cannon brett at python.org
Sun Apr 22 00:17:19 CEST 2012

On Sat, Apr 21, 2012 at 12:10, Barry Warsaw <barry at python.org> wrote:

On Apr 20, 2012, at 09:59 PM, Brett Cannon wrote:

>As I clean up Python/import.c and move much of its functionality into >Lib/imp.py, I am about to run into some stuff that was not kept private to >the file. Specifically, I have PyImportGetMagicTag() and NullImporterType >which I would like to chop out and move to Lib/imp.py. > >>From my reading of PEP 384 that means I would need to at least deprecate >PyImportgetMagicTag(), correct (assuming I follow through with this; I >might not bother)? What about NullImporterType (it lacks a Py prefix so I >am not sure if this is considered public or not)? I'd have to go back into my archives for the discussions about the PEP, but my recollection is that we intentionally made PyImportGetMagicTag() a public API method. Thus no leading underscore. It's a bug that it's not documented, but OTOH, it's unlikely there are, or would be, many consumers for it. Strictly speaking, I do think you need to deprecate the APIs. I like Nick's suggestion to make them C wrappers which just call back into Python.

That was my plan, but the amount of code it will take to wrap them is making me not care. =) For PyImport_GetMagicTag() I would need to expose a new attribute on sys or somewhere which specifies the VM name. For PyImport_GetMagicNumber() I have to do a bunch of bit twiddling to convert a bytes object into a long which I am just flat-out not in the mood to figure out how to do. And all of this will lead to the same amount of C code as there currently is for what is already implemented, so I just don't care anymore. =)

But I'm glad the clarifications are there about the stable ABI and how we are handling it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120421/4781809b/attachment.html>

More information about the Python-Dev mailing list