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: