thecodingchicken
diff --git a/‎future/__init__.py‎
Lines changed: 108 additions & 63 deletions b/‎future/__init__.py‎
Lines changed: 108 additions & 63 deletions
diff --git a/‎future/common_iterators.py‎
Lines changed: 9 additions & 7 deletions b/‎future/common_iterators.py‎
Lines changed: 9 additions & 7 deletions
diff --git a/‎future/disable_obsolete_builtins.py‎
Lines changed: 21 additions & 15 deletions b/‎future/disable_obsolete_builtins.py‎
Lines changed: 21 additions & 15 deletions
diff --git a/‎future/modified_builtins/newsuper.py‎
Lines changed: 1 addition & 1 deletion b/‎future/modified_builtins/newsuper.py‎
Lines changed: 1 addition & 1 deletion
@@ -15,17 +15,23 @@
     from __future__ import (division, absolute_import, print_function,
                             unicode_literals)
     from future import *
-
+    
 followed by clean Python 3 code (with a few restrictions) that can run
-unchanged on Python 2.7 or Python 3.3. For example::
+unchanged on Python 2.7.
+
+On Python 3, the ``from future import *`` line has no effect (i.e. no
+namespace pollution.) On Python 2 it shadows builtins to provide the
+Python 3 semantics. (See below for the explicit import form.)
 
-    # New range object with slicing support
+For example::
+
+    # New iterable range object with slicing support
     for i in range(10**11)[:10]:
         pass
     
     # Other common iterators: map, reduce, zip
-    iter = zip(range(3), ['a', 'b', 'c'])
-    assert iter != list(iter)
+    my_iter = zip(range(3), ['a', 'b', 'c'])
+    assert my_iter != list(my_iter)
     
     # New simpler super() function:
     class VerboseList(list):
@@ -39,25 +45,31 @@ def append(self, item):
     # This identity is restored. This is normally valid on Py3 and Py2, but
     # 'from __future__ import unicode_literals' breaks it on Py2:
     assert isinstance('happy', str)
-    
-See below for more explicit forms of the import line.
-    
-Another feature offered is support for the standard library
-reorganization (PEP 3108)::
-    
+
+    # The round() function behaves as it does in Python 3, using "Banker's
+    # Rounding" to the nearest even last digit:
+    assert round(0.1250, 2) == 0.12
+
+    # input() is now safe (no eval()):
+    name = input('What is your name?\n')
+    print('Hello ' + name)
+
+``future`` also supports the standard library reorganization (PEP 3108)
+via import hooks, allowing standard library modules to be accessed under
+their Python 3 names and locations::
+
     from future import standard_library_renames
-    
+
     import socketserver
     import queue
     import configparser
-    # etc.
+    # and other moved modules
 
-and other modules renamed for Python 3.
-
-The above * import is equivalent to::
+If you prefer explicit imports, the explicit equivalent of the ``from
+future import *`` line above is::
     
     from future.common_iterators import zip, map, filter
-    from future.features import range, super
+    from future.modified_builtins import (range, super, round, input)
     from future.disable_obsolete_builtins import (apply, cmp, coerce,
             execfile, file, long, raw_input, reduce, reload, unicode,
             xrange, StandardError)
@@ -68,7 +80,7 @@ def append(self, item):
     
 - future.standard_library_renames
 - future.common_iterators
-- future.features
+- future.modified_builtins
 - future.disable_obsolete_builtins
 - future.str_as_unicode
 
@@ -126,9 +138,17 @@ def append(self, item):
 
 :Q: Why is there a need for this?
 
-:A: To reduce cruft in single-source codebases that support both Python 2
-    and 3.
+:A: "Python 2 is the next COBOL." - Alex Gaynor, at PyCon AU 2013
+
+    Python 3.3 is a better language and better set of standard libraries
+    than Python 2.x in almost every way.
 
+    ``future`` helps you to take advantage of the cleaner syntax and
+    semantics of Python 3 code today while still supporting Python 2.
+    
+    The goal is to encourage writing future-proof code while still
+    supporting the platform of today.
+    
 
 Other compatibility tools
 -------------------------
@@ -174,25 +194,6 @@ def greet(name):
     http://www.youtube.com/watch?v=xNZ4OVO2Z_E.)
 
 
-:Q: What is the relationship between this project and ``python-modernize``?
-
-:A: ``python-modernize`` is great, and this project is designed to
-    complement it.  For a project wishing to migrate to Python 3,
-    python-modernize is useful for starting the process of cleaning up
-    legacy code idioms which would cause SyntaxErrors on Python 3. The
-    output of ``python-modernize`` should hopefully be a valid common
-    subset of Python 3 and Python 2 that should run under either
-    platform.
-
-    However, the output of ``python-modernize`` is not clean Python 3
-    code; it requires that code contain various backward-compatibility
-    warts and a runtime dependency on the six module.
-    
-    ``future`` goes further in allowing either the output of
-    ``python-modernize`` or hand-written Python 3 code to run with less
-    work and and less backward-compatible cruft on Python 2.
-
-
 :Q: What is the relationship between this project and ``six``?
 
 :A: ``future`` is a higher-level interface that incorporates the ``six``
@@ -201,26 +202,43 @@ def greet(name):
     the interface they offer, the Python versions they target, and the
     extent of the support they offer for new Python 3 features.
     
-    Codebases that use ``six`` are sometimes standard Python 3 code,
-    sometimes Python 2 code, and sometimes neither (``six``-specific
-    wrapper interfaces).
+    Although ``six`` is a remarkable achievement -- making it possible to
+    write a single-source codebase that runs on both Python 2 and Python
+    3 -- codebases that use ``six`` directly tend to be mixtures of
+    Python 2 code, Python 3 code, and ``six``-specific wrapper
+    interfaces. In practice it often looks like this::
     
-    Here is a simple example of code compatible with both Python 2 and
-    Python 3 using ``six``::
+        from sklearn.externals.six.moves import (cStringIO as StringIO,
+                                                 xrange)
+
+        for i, (k, v) in enumerate(sorted(six.iteritems(params))):
+            # ...
+
+        if six.PY3:
+            exec(open('setup.py').read(), {'__name__'='__main__'})
+        else:
+            execfile('setup.py', {'__name__'='__main__'})
     
-        from six.moves import xrange
-        for i in xrange(10**10):    # non-standard Python 3 code
+        for i in xrange(10**10):        # non-standard Python 3
             pass
     
-    Here is the corresponding example using the ``future`` module::
+
+    This is crufty and non-standard Python 3 code that puts a maintenance
+    burden on the code to support Python 2 indefinitely.
+
+    Here is the equivalent code using the ``future`` module::
+    
+        from future import standard_library_renames, range
+
+        for i, (k, v) in enumerate(sorted(params.items())):
+            # ...
+
+        exec(open('setup.py').read(), {'__name__'='__main__'})
     
-        from future.features import range
         for i in range(10**10):     # standard Python 3
             pass
     
-    Note that the former introduces the obsolete xrange() back into the
-    codebase in order to offer backward compatibility for Python 2. The
-    latter example is standard Python 3 code, with an import line that
+    This is standard Python 3 code, with an import line that
     has no effect on Python 3.
     
     Another difference is version support: ``future`` supports only
@@ -230,10 +248,25 @@ def greet(name):
     functions) are superseded by features introduced in Python 2.6 or
     2.7.
 
-    The final difference is that ``future`` offers some backported features
+    The final difference is in scope: ``future`` offers more backported features
     from Python 3, including the improved no-argument super() function,
-    and the new range object (with slicing support). More backported
-    features will be added in the future.
+    the new range object (with slicing support), rounding behaviour, etc.
+    More backported features will be added in the future. This should
+    reduce the burden on every project to roll its own py3k compatibility
+    wrapper module.
+
+:Q: What is the relationship between this project and ``python-modernize``?
+
+:A: For a project wishing to migrate to Python 3, python-modernize is
+    very useful for starting the process of cleaning up legacy code
+    idioms which would cause SyntaxErrors on Python 3. The output of
+    ``python-modernize`` should hopefully be a valid common subset of
+    Python 3 and Python 2 that should run under either platform.
+
+    Currently, python-modernize produces code with a run-time dependency
+    on ``six`` (see above). We will aim to provide an alternative set of
+    fixes for ``python-modernize`` to produce cleaner Python 3 code using
+    ``future`` as an alternative depencency to ``six``.
 
 
 :Q: How did the original need for this arise?
@@ -254,7 +287,7 @@ def greet(name):
     for at least the next 5 years, one of the promised benefits of Python
     3 -- cleaner code with fewer of Python 2's warts -- was difficult to
     realise before in practice in a single codebase that supported both
-    versions.
+    platforms.
 
 
 :Q: Do you support Pypy?
@@ -271,23 +304,35 @@ def greet(name):
 
 :A: Yes, we welcome bug reports, tests, and pull requests.
 
+
 """
 
 from __future__ import (division, absolute_import, print_function)
 
-from future.common_iterators import *
-from future.features import *
-from future.disable_obsolete_builtins import *
-from future.str_is_unicode import *
+from future import six
+
+if not six.PY3:
+    from future.common_iterators import (filter, map, zip)
+    from future.disable_obsolete_builtins import (apply, cmp, coerce,
+            execfile, file, long, raw_input, reduce, reload, unicode,
+            xrange, StandardError)
+    from future.modified_builtins import (round, input, range, super)
+    from future.str_is_unicode import str  # not python_2_unicode_compatible
+    
+    # Only shadow builtins on Py2; no new names
+    __all__ = ['filter', 'map', 'zip', 'apply', 'cmp', 'coerce', 'execfile',
+               'file', 'long', 'raw_input', 'reduce', 'reload', 'unicode',
+               'xrange', 'StandardError', 'round', 'input', 'range', 'super',
+               'str']
 
+else:
+    # No namespace pollution on Py3
+    __all__ = []
 
 __ver_major__ = 0
-__ver_minor__ = 1
+__ver_minor__ = 2
 __ver_patch__ = 0
 __ver_sub__ = ''
 __version__ = "%d.%d.%d%s" % (__ver_major__,__ver_minor__,__ver_patch__,__ver_sub__)
-VERSION = __version__
 
-# __all__ = ['disable_obsolete_builtins', 'common_iterators', 'str_is_unicode',
-#            'standard_library_renames', 'features']
 
@@ -1,34 +1,36 @@
 """
-This module is designed to be used as follows:
+This module is designed to be used as follows::
 
     from __future__ import division, absolute_import, print_function
     from future.common_iterators import *
 
-And then, for example:
+And then, for example::
 
     for i in range(10**10):
         pass
-
+    
     for (a, b) in zip(range(10**10), range(-10**10, 0)):
         pass
 
 Note that this is standard Python 3 code, plus some imports that do
 nothing on Python 3.
 
-The iterators this brings in are:
+The iterators this brings in are::
+
 - range
 - filter
 - map
 - zip
 
 range is equivalent to xrange on Python 2 by default. As an alternative,
 there is a pure Python backport of Python 3's range iterator available
-with slicing support. To use it, add:
+with slicing support. To use it, add::
 
-    from future.features import range
+    from future.modified_builtins import range
 
 The other iterators (filter, map, zip) are from the itertools module on
-Python 2.
+Python 2. Note that these are also available in the ``future_builtins``
+module on Python 2 (but not Python 3).
 """
 
 from __future__ import division, absolute_import, print_function
 
@@ -13,31 +13,36 @@
 
 The following functions are disabled:
 
-    apply, cmp, coerce, execfile, file, long,
+    apply, cmp, coerce, execfile, file, input, long,
     raw_input, reduce, reload, unicode, xrange
 
-and this exception class:
+Note that both input() and raw_input() are disabled. Although input()
+exists as a builtin in Python 3, the Python 2 input() builtin is unsafe
+to use because it can lead to shell injection. Therefore we shadow it by
+default, in case someone forgets to import our replacement input()
+somehow and expects Python 3 semantics.
 
-    StandardError
+Fortunately, input() seems to be seldom used in the wild in Python 2, so
+we could probably even delete it from __builtin__... TODO: test this.
+
+(Note that callable() is not among the functions disabled; this was
+reintroduced into Python 3.2.)
 
-(Note that callable() is not among them; this was reintroduced into
-Python 3.2.)
+This exception class is also disabled:
+
+    StandardError
 
-Also to do:
-- Fix round()
-- Fix input()
-- Fix int()
 """
 
 from __future__ import division, absolute_import, print_function
 
 import inspect
 
-from . import six
+from future import six
 
-OBSOLETE_BUILTINS = ['apply', 'cmp', 'coerce', 'execfile', 'file', 'long',
-                     'raw_input', 'reduce', 'reload', 'unicode', 'xrange',
-                     'StandardError']
+OBSOLETE_BUILTINS = ['apply', 'cmp', 'coerce', 'execfile', 'file',
+                     'input', 'long', 'raw_input', 'reduce', 'reload',
+                     'unicode', 'xrange', 'StandardError']
 
 
 def disabled_function(name):
@@ -54,8 +59,9 @@ def disabled(*args, **kwargs):
 
 
 if not six.PY3:
-    caller = inspect.currentframe().f_back
+    # caller = inspect.currentframe().f_back
 
     for fname in OBSOLETE_BUILTINS:
-        caller.f_globals.__setitem__(fname, disabled_function(fname))
+        # caller.f_globals.__setitem__(fname, disabled_function(fname))
+        locals()[fname] = disabled_function(fname)
 
@@ -3,7 +3,7 @@
 behaviour of super() in Python 3. It is designed to be used as follows:
 
     from __future__ import division, absolute_import, print_function
-    from future.features import super
+    from future.modified_builtins import super
 
 And then, for example: