[Python-porting] python-future and six

[M.-A. Lemburg]

On 11.06.2015 01:33, Clay Gerrard wrote:
> OpenStack [1] has been using six to handle python 2/3 compatibility in a
> number of places and is making good progress!  With eventlet now running a
> python2/3 compatible code base (Segrey went with the just inline six
> approach [2]) things are really starting to move quickly!  Lots of patches
> coming up with stuff imported from six.moves and isinstance
> six.strings_type everywhere - not so much six.b and six.u though - as the
> OpenStack projects already targets >=2.7 or >=3.3 (maybe even >=3.4?).
> 
> But, I'm finding myself wondering what we're going to do with all these
> references to six in our code base once we drop python 2.7 support?  Is it
> worth it [3]?
> 
> Also I was looking at Brett Cannon's updates to the official porting guide
> [4] which now references *both* six and python-future [5]?  I sorta like
> the idea that python-future might let me write more or less idiomatic
> python3 code* and it will just work on python2?
> 
> * as idiomatic as writing python 1.6 code felt on python 2.3 anyway :)
> 
> So I've got at least these many choices:
> 
>  * modernize + roll your own compat layer for stdlib imports
>  * inline six
>  * depend on six
>  * depend on python-future
> 
> OpenStack so far seems to have picked "depend on six" so it's probably
> easiest to stick with the momentum - unless the momentum is heading us
> towards a cliff?
> 
> Is there any hope the experts on the state of the art could tell me the
> "one-- and preferably only one --obvious way to do it"?  :)

As you can see from the development of available tools, there
is no obvious way to do it :-)

In the early days, people suggested doing the conversion to
Python 3 once and then forget about Python 2 or maintain two
branches. Didn't work out.

Then the idea was to continue writing Python 2 code
and use 2to3 during installation to create the Python 3
code. Resulted in very poor Python 3 code and poor Python 2
code due to the workarounds needed to make the automatic
conversion work. Way too fragile.

Next was six to help write new code which works in both Python 2
and 3; and later python-modernize and similar tools to help
convert Python 2 to runs-on-both-code.

Then people were concerned about a possible extra future effort
to drop Python 2 support in their code base. python-future
was born.

IMO, Armin Ronacher's approach works best if you have a
large code base and fans in both Python 2 and 3 camps.
Using various bits from six in your compat layer helps,
but be careful not to introduce too many indirections
to not slow down your code too much.

If you're writing Python 3 code mostly, you may want to
consider using python-future to also ship a Python 2
port.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 11 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2015-07-20: EuroPython 2015, Bilbao, Spain ...             39 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/