Reject 294's proposed updates to the "types" and "new" modules.

Instead, missing type names can be added to __builtin__ or sys.

pep-0000.txt

@@ -85,7 +85,6 @@ Index by Category
  S   280  Optimizing access to globals                 GvR
  S   286  Enhanced Argument Tuples                     von Loewis
  I   287  reStructuredText Docstring Format            Goodger
- S   294  Type Names in the types Module               Tirosh
  S   297  Support for System Upgrades                  Lemburg
  S   298  The Locked Buffer Interface                  Heller
  S   299  Special __main__() function in modules       Epler
@@ -201,6 +200,7 @@ Index by Category
  SR  281  Loop Counter Iteration with range and xrange Hetland
  SR  284  Integer for-loops                            Eppstein, Ewing
  SR  288  Generators Attributes and Exceptions         Hettinger
+ SR  294  Type Names in the types Module               Tirosh
  SR  295  Interpretation of multiline string constants Koltsov
  SR  296  Adding a bytes Object Type                   Gilbert
  SR  303  Extend divmod() for Multiple Divisors        Bellman
@@ -336,7 +336,7 @@ Numerical Index
  I   291  Backward Compatibility for Standard Library  Norwitz
  SF  292  Simpler String Substitutions                 Warsaw
  SF  293  Codec Error Handling Callbacks               Dörwald
- S   294  Type Names in the types Module               Tirosh
+ SR  294  Type Names in the types Module               Tirosh
  SR  295  Interpretation of multiline string constants Koltsov
  SR  296  Adding a bytes Object Type                   Gilbert
  S   297  Support for System Upgrades                  Lemburg

pep-0294.txt

@@ -3,10 +3,10 @@ Title: Type Names in the types Module
 Version: $Revision$
 Last-Modified: $Date$
 Author: oren at hishome.net (Oren Tirosh)
-Status: Draft
+Status: Rejected
 Type: Standards track
 Created: 19-Jun-2002
-Python-Version: 2.3
+Python-Version: 2.5
 Post-History:
 
 
@@ -29,6 +29,21 @@ Abstract
     PEP 4.
 
 
+Pronouncement
+
+    A centralized repository of type names was a mistake.  Neither the
+    "types" nor "new" modules should be carried forward to Python 3.0.
+
+    In the meantime, it does not make sense to make the proposed updates
+    to the modules.  This would cause disruption without any compensating
+    benefit.
+
+    Instead, the problem that some internal types (frames, functions,
+    etc.) don't live anywhere outside those modules may be addressed by
+    either adding them to __builtin__ or sys.  This will provide a
+    smoother transition to Python 3.0.
+    
+
 Rationale
 
     Using two sets of names for the same objects is redundant and