[Python-Dev] Handling deprecations in the face of PEP 384

[Brett Cannon]

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
> NullImporter_Type
> >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
> 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>