[Python-checkins] r83347 - peps/trunk/pep-3151.txt

[antoine.pitrou]

Author: antoine.pitrou
Date: Sat Jul 31 19:44:39 2010
New Revision: 83347

Log:
Suggesting a mechanism for deprecation of old exception names



Modified:
   peps/trunk/pep-3151.txt

Modified: peps/trunk/pep-3151.txt
==============================================================================
--- peps/trunk/pep-3151.txt	(original)
+++ peps/trunk/pep-3151.txt	Sat Jul 31 19:44:39 2010
@@ -251,9 +251,34 @@
 --------------------
 
 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: