9

I am starting to learn Python, but I'm forced to use a v2.6.2 interpreter.

I want to get as close as possible to Python 3, e.g, using the new print function, "true" division, etc.

from __future__ import division
from __future__ import print_function
print(1/2, file=sys.stderr) # 0.5

What other features should I import from __future__?

I guess I could do a general import __future__ but then I would get different behavior when I upgrade to a higher version (v2.7 might have more features in __future__), and my scripts might stop working then.

Frank
  • 64,140
  • 93
  • 237
  • 324
  • Are you sure this is wise? If you are forced to use Python 2.x, and you start writing code in the style of Python 3.x, won't whoever is compelling you to use 2.x complain? – David Heffernan Mar 27 '12 at 21:35
  • 1
    @DavidHeffernan: No, I can write my scripts however I want. It's just that I'm on an old computer that has Python v2.6.2 installed, and installing Python v3 in addition doesn't seem to be an option. – Frank Mar 27 '12 at 21:36
  • 1
    Installing Python 3 is totally an option – Amber Mar 27 '12 at 21:37
  • Consider yourself lucky; I have to prod people to install Python 2.5 because the boxes only have 2.3 or 2.4 installed, and I want to use `with`! :-) – torek Mar 27 '12 at 21:37
  • @Amber: My sysadmins don't want to do it, and compiling it myself was not successful (other packages would need to be upgraded too). – Frank Mar 27 '12 at 21:38
  • 1
    @Frank Just get a portable Python 3.x installation then. You don't need to install anything that way, just copy it onto your desktop and run if from there. – David Heffernan Mar 27 '12 at 21:39
  • 4
    `from __future__ import` is a __future statement__, not an import statement -- it has special semantics. `import __future__` is just a regular import -- it doesn't change anything. – agf Mar 27 '12 at 21:45
  • @DavidHeffernan: Does portable Python 3 have all the standard modules that Python 3 has? It looks like it's restricted (http://www.portablepython.com/wiki/PortablePython3.2.1.1)? – Frank Mar 27 '12 at 21:47
  • You read that wrong. That's a list of additional packages! I've never used it but I'd be astounded if you didn't have all you need. Anyway, you said you are starting to learn. You don't need esoteric 3rd party modules. – David Heffernan Mar 27 '12 at 21:50
  • @DavidHeffernan: Thanks, good to know. It looks like portable python is for windows only, though. I am using Linux. – Frank Mar 27 '12 at 22:18

2 Answers2

7

Well, even if there wasn't documentation, __future__ is also a regular module that has some info about itself:

>>> import __future__
>>> __future__.all_feature_names
['nested_scopes', 'generators', 'division', 'absolute_import', 'with_statement', 'print_function', 'unicode_literals']
>>> __future__.unicode_literals
_Feature((2, 6, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 131072)

Python 2.6 has most of the features already enabled, so choose from division, print_function, absolute_import and unicode_literals.

And no, import __future__ won't work as you think. It's only magic when you use the from __future__ import something form as the first statement in the file. See the docs for more.

Of course, no matter how much you import from __future__, you will get different behavior in 3.x.

Petr Viktorin
  • 65,510
  • 9
  • 81
  • 81
  • I would skip `unicode_literals`, see http://stackoverflow.com/questions/809796/any-gotchas-using-unicode-literals-in-python-2-6 – agf Mar 27 '12 at 21:49
  • 1
    @agf those are ways that the code might break if you just blindly add `unicode_literals`, but they simply point to things that ought to be fixed anyway, really. Python 3's approach to unicode is simply more sensible. – Karl Knechtel Mar 27 '12 at 21:59
  • @KarlKnechtel Either Nick Coglan or Raymond Hettinger reccomended against using it, saying that including it in `__future__` was a mistake. I don't remember if it was here on SO or in a blog post. I just used that link because I can't find the one I'm thinking of right now. – agf Mar 27 '12 at 22:03
  • It's true that the resulting behaviour isn't *quite* like in 3.x. – Karl Knechtel Mar 27 '12 at 22:03
  • 1
    Using UTF-8 encoded bytestrings anywhere but on input/output is a bad idea anyway. At least it breaks loudly this way, instead of giving incorrect results or breaking on some machines but not others. – Petr Viktorin Mar 27 '12 at 22:05
7

What other features should I import from __future__?

To get the most up-to-date behaviour, you should of course import every __future__ feature that's offered, except the ones that you get anyway. (The way the system is set up, old features are not dropped even after they're always-on.)

Note that import __future__ will not give you everything, and neither will from __future__ import *. The from ... import ... syntax is special-cased for __future__ (which is how it works), but __future__ is still a real module that you can import with import __future__. However, doing so will let you know the actual feature names, as well as information on when they were (or are expected to be) made default, and when they became available.

>>> [
...     name for name in __future__.all_feature_names if
...     getattr(__future__, name).optional <=
...     sys.version_info <
...     getattr(__future__, name).mandatory
... ]

['division', 'print_function', 'unicode_literals']

is what I get on 2.7.2.

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153