From 8bf0e8e43792b5af8cb908cfb6ad6fee4563fbb3 Mon Sep 17 00:00:00 2001 From: Antoine Pitrou Date: Sat, 31 Jul 2010 17:44:39 +0000 Subject: [PATCH] Suggesting a mechanism for deprecation of old exception names --- pep-3151.txt | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/pep-3151.txt b/pep-3151.txt index 04fd20b5b..70ce046db 100644 --- a/pep-3151.txt +++ b/pep-3151.txt @@ -251,9 +251,34 @@ Deprecation of names -------------------- It is not yet decided whether the old names will be deprecated (then removed) -or all alternative names will continue living in the root namespace. -Deprecation of names from the root namespace presents some implementation -challenges, especially where performance is important. +or all names will continue living forever in the builtins namespace. + +built-in exceptions +''''''''''''''''''' + +Deprecating the old built-in exceptions cannot be done in a straightforward +fashion by intercepting all lookups in the builtins namespace, since these +are performance-critical. We also cannot work at the object level, since +the deprecated names will be aliased to non-deprecated objects. + +A solution is to recognize these names at compilation time, and +then emit a separate ``LOAD_OLD_GLOBAL`` opcode instead of the regular +``LOAD_GLOBAL``. This specialized opcode will handle the output of a +DeprecationWarning (or PendingDeprecationWarning, depending on the policy +decided upon) when the name doesn't exist in the globals namespace, but +only in the builtins one. This will be enough to avoid false positives +(for example if someone defines their own ``OSError`` in a module), and +false negatives will be rare (for example when someone accesses ``OSError`` +through the ``builtins`` module rather than directly). + +module-level exceptions +''''''''''''''''''''''' + +The above approach cannot be used easily, since it would require +special-casing some modules when compiling code objects. However, these +names are by construction much less visible (they don't appear in the +builtins namespace), and lesser-known too, so we might decide to let them +live in their own namespaces. .. _Step 2: