[Python-Dev] Handling deprecations in the face of PEP 384
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 PyImport_GetMagicTag() and
> >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
> >PyImport_getMagicTag(), correct (assuming I follow through with this; I
> >might not bother)? What about NullImporter_Type (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 PyImport_GetMagicTag() a public
> method. Thus no leading underscore. It's a bug that it's not documented,
> 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
> 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...
More information about the Python-Dev