[anaconda][master][PATCH 0/9] More Python 3 compatibility

Martin Kolman mkolman at redhat.com
Thu Jan 29 11:25:41 UTC 2015


On Thu, 2015-01-29 at 09:10 +0100, Vratislav Podzimek wrote:
> On Wed, 2015-01-28 at 18:43 +0100, Martin Kolman wrote:
> > Most of the easy to change, non-invasive Python 3 compatibility
> > changes have been done a while ago. This patch set contains more
> > complicated and invasive changes, but still without breaking Python 2
> > support.
> > 
> > Also while working on the patch set I've made a preliminary list of
> > the *invasive* changes that *do* break Python 2 compatibility,
> > but are needed to make Anaconda Python 3 compatible:
> > 
> > - switch to Python 3 versions of dependencies in spec file
> > - switch to use python3 in the main anaconda script:
> >  - #!/usr/bin/python3
> > - replace types.StringType with str or bytes (depending on data being processed)
> > - replace types.UnicodeType with str
> > - replace all unicode() calls with str()
> > - import Queue -> import queue
> > - import ConfigParser -> import configparser
> > - remove from __future__ import print_function
> > - adapt metaclass usage
> >  - 2to3 -f metaclass .
> > - replace xrange with range
> > - replace next() with __next__() for custom iterators
> Huh? Do you mean the .next() method? Because AFAICT, next(itr) is the
> recommended way to work with iterators in Python3.
This is for custom iterator classes - in Python 2 you would implement a
next() method to make the class be an iterator, but in Python 3 this has
been changed to __next__(), most probably to be consistent with all the
other "special" methods like __init__(), __repr__() etc.

The next() function to be called with an iterator as its parameter is of
course the preferred way of manually yielding stuff from iterators. 

But looking a bit deeper into the next() -> __next__() change, it seems
that it has been backported to 2.6+:
http://docs.pythonsprints.com/python3_porting/py-porting.html#creating-iterators

So this can be removed from the "breaking" list and changed now without
breaking Python 2 compatibility.
> 
> > - replace raw_input() with input()
> > 
> > These two together + dropping of the few remaining Python 2-only dependencies
> > (pyblock, something else ?) should more or less give us a Python 3 Anaconda.
> That doesn't seem too bad to me. Thanks for the report!
>



More information about the anaconda-patches mailing list