mitsuhiko  committed 6be3793

Removed Python 2.2 compatiblity.

  • Participants
  • Parent commits 61f81f6
  • Branches default

Comments (0)

Files changed (1)

File pep-0333.txt

 canonical form.
-.. comment:
-   Remove this section?
-Supporting Older (<2.2) Versions of Python
-Some servers, gateways, or applications may wish to support older
-(<2.2) versions of Python.  This is especially important if Jython
-is a target platform, since as of this writing a production-ready
-version of Jython 2.2 is not yet available.
-For servers and gateways, this is relatively straightforward:
-servers and gateways targeting pre-2.2 versions of Python must
-simply restrict themselves to using only a standard "for" loop to
-iterate over any iterable returned by an application.  This is the
-only way to ensure source-level compatibility with both the pre-2.2
-iterator protocol (discussed further below) and "today's" iterator
-protocol (see PEP 234).
-(Note that this technique necessarily applies only to servers,
-gateways, or middleware that are written in Python.  Discussion of
-how to use iterator protocol(s) correctly from other languages is
-outside the scope of this PEP.)
-For applications, supporting pre-2.2 versions of Python is slightly
-more complex:
-* You may not return a file object and expect it to work as an iterable,
-  since before Python 2.2, files were not iterable.  (In general, you
-  shouldn't do this anyway, because it will peform quite poorly most
-  of the time!)  Use ``wsgi.file_wrapper`` or an application-specific
-  file wrapper class.  (See `Optional Platform-Specific File Handling`_
-  for more on ``wsgi.file_wrapper``, and an example class you can use
-  to wrap a file as an iterable.)
-* If you return a custom iterable, it **must** implement the pre-2.2
-  iterator protocol.  That is, provide a ``__getitem__`` method that
-  accepts an integer key, and raises ``IndexError`` when exhausted.
-  (Note that built-in sequence types are also acceptable, since they
-  also implement this protocol.)
-Finally, middleware that wishes to support pre-2.2 versions of Python,
-and iterates over application return values or itself returns an 
-iterable (or both), must follow the appropriate recommendations above.
-(Note: It should go without saying that to support pre-2.2 versions
-of Python, any server, gateway, application, or middleware must also
-use only language features available in the target version, use
-1 and 0 instead of ``True`` and ``False``, etc.)
 Optional Platform-Specific File Handling
 Apart from the handling of ``close()``, the semantics of returning a
 file wrapper from the application should be the same as if the
-application had returned ``iter(, '')``.  In other words,
+application had returned ``iter(filelike)``.  In other words,
 transmission should begin at the current position within the "file"
 at the time that transmission begins, and continue until the end is
 the ``wsgi.file_wrapper`` **must** still return an iterable that wraps
 ``read()`` and ``close()``, so that applications using file wrappers
 are portable across platforms.  Here's a simple platform-agnostic
-file wrapper class, suitable for old (pre 2.2) and new Pythons alike::
+file wrapper class::
-    class FileWrapper:
+    class FileWrapper(object):
         def __init__(self, filelike, blksize=8192):
             self.filelike = filelike
             if hasattr(filelike, 'close'):
                 self.close = filelike.close
-        def __getitem__(self, key):
+        def __iter__(self):
             data =
-            if data:
-                return data
-            raise IndexError
+            if not data:
+                raise StopIteration()
+            return data
 and here is a snippet from a server/gateway that uses it to provide
 access to a platform-specific API::
 * Changed the signature of ``environ['wsgi.input'].readline(hint)`` to
   allow the ``hint`` argument.
+* Removed Python 2.2 compatibility mentionings in the PEP because these
+  versions are no longer in use.
 Questions and Answers