[Python-Dev] Handling deprecations in the face of PEP 384 (original) (raw)
Brett Cannon brett at python.org
Sun Apr 22 00:13:57 CEST 2012
- Previous message: [Python-Dev] Handling deprecations in the face of PEP 384
- Next message: [Python-Dev] Expose dictproxy through collections rather than the types module?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Apr 21, 2012 at 16:55, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> 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)?
All that PEP 384 gives you is that you MAY deprecate certain API (namely, all API not guaranteed as stable). If an API is not in the restricted set, this doesn't mean that it SHOULD be deprecated at some point. So there is no need to deprecate anything.
I meant "at least deprecate" as in "I can't just remove it from Python 3.3".
-Brett
OTOH, if the new implementation cannot readily support the API anymore, it can certainly go away. If it was truly private (i.e. Py*), it can go away immediately. Otherwise, it should be deprecated-then-removed. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120421/f8cad7d0/attachment.html>
- Previous message: [Python-Dev] Handling deprecations in the face of PEP 384
- Next message: [Python-Dev] Expose dictproxy through collections rather than the types module?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]