Python 2 / 3 compatibility, like six, but favouring Python 3
When the best Python 2/Python 3 compatibility modules – especially the famous *six* library invented by Benjamin Peterson – were created, they were written from the point of view of a Python 2 programmer starting to grok Python 3.
But it is 2016. Python 3.5 is here. 3.5!!!
If you use six, your code is compatible, but stuck in Python 2 idioms.
nine turns six upside down. You write your code using Python 3 idioms – as much as possible –, and it is the Python 2 “version” that is patched. Needless to say, this approach is more future-proof.
When thou writeth Python, thou shalt write Python 3 and, just for a little longer, ensure that the thing worketh on Python 2.7.
Honestly you should not spend one thought on Python 2.6 anymore, it is no longer supported since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
Python 2.7 will finally meet its demise in the year 2020. So, starting now, thine codebase shall look more like 3 than 2.
nine facilitates this point of view. You can write code that is as 3ish as possible while still supporting 2.6. Very comfortable for new projects.
For instance, you don’t type unicode anymore, you type str, and nine makes str point to unicode on Python 2 (if you use our boilerplate). Also, map, zip and filter have Python 3 behaviour, on Python 2, meaning they return iterators, not lists.
The author(s) of nine donate this module to the public domain.
To understand most of the intricacies involved in achieving 2&3 compatibility in a single codebase, I recommend reading this: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
In each of your modules, start by declaring a text encoding and importing Python 3 behaviours from __future__. Then import variables from nine, as per this boilerplate:
# -*- coding: utf-8 -*- from __future__ import (absolute_import, division, print_function, unicode_literals) from nine import (IS_PYTHON2, str, basestring, native_str, chr, long, integer_types, class_types, range, range_list, reraise, iterkeys, itervalues, iteritems, map, zip, filter, input, implements_iterator, implements_to_string, implements_repr, nine, nimport)
I know that is ugly. What did you expect? nine is 3 squared. OK, in many cases you can get away with less:
# -*- coding: utf-8 -*- from __future__ import (absolute_import, division, print_function, unicode_literals) from nine import IS_PYTHON2, nimport, nine, range, str, basestring
But in the second case you need to remember to import the missing stuff when you use it, and it is not realistic to expect that you will remember, is it?
Because of the unicode_literals import, all string literals in the module become unicode objects. No need to add a “u” prefix to each string literal. This is the saner approach since in Python 3 strings are unicode objects by default, and you can then indicate b"this is a byte string literal". The literals that actually need to be byte strings are very rare. But you wouldn’t believe how many developers are irrationally afraid of taking this simple step…
If you don’t know much about Unicode, just read The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Many standard library modules were renamed in Python 3, but nine can help. The nimport function gets the new Python 3 name, but knows to import the old name if running in Python 2. For instance, instead of writing this to import pickle:
# Bad: try: import cPickle as pickle # Python 2.x except ImportError: import pickle # Python 3 automatically uses the C version.
…you can write this:
# Good: pickle = nimport('pickle')
For variables that have been moved: In the argument, please separate the module from the variable with a colon:
name2codepoint = nimport('html.entities:name2codepoint')
Want StringIO? I recommend you build lists instead. But if you really need it:
# Good: if IS_PYTHON2: from cStringIO import StringIO as BytesIO, StringIO NativeStringIO = BytesIO else: from io import BytesIO, StringIO NativeStringIO = StringIO
Our coverage of Python version differences probably isn’t exhaustive, but contributions are welcome.
When in doubt, use the source!
We provide a class decorator for Python 2 and 3 compatibility of magic methods. Magic methods are those that start and end with two underlines.
You define the magic methods with their Python 3 names and, on Python 2, they get their corresponding names. You may write:
@nine class MyClass(object): def __str__(self): return "MyClass" # a unicode string
When you are starting to apply nine on Python 2 code to achieve Python 3 compatibility, you can start by following this list of tasks. It isn’t exhaustive, just a good start. You can upgrade one .py module at a time:
If you had been using six or another compatibility library before:
Then run your tests in all the Python versions you wish to support.
If I forgot to mention anything, could you make a pull request, for the benefit of other developers?
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|File Name & Checksum SHA256 Checksum Help||Version||File Type||Upload Date|
|nine-1.0.0-py2.py3-none-any.whl (12.7 kB) Copy SHA256 Checksum SHA256||3.5||Wheel||May 22, 2016|
|nine-1.0.0.tar.gz (8.8 kB) Copy SHA256 Checksum SHA256||–||Source||May 22, 2016|