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

Martin Kolman mkolman at redhat.com
Thu Jan 29 16:57:23 UTC 2015


On Thu, 2015-01-29 at 12:25 +0100, Martin Kolman wrote:
> 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.
After further investigation, it turns out to be breaking, as even thigh
the next() function has been backported to Python 2.6+, it calls the
next() method of the iterator, not __next__(). So changing this the
"right" way (replacing direct calls with calling next() on the iterators
and replacing next() with __next__() for custom iterator classes) is
still breaking Python 2 compatibility. 

Hacks like defining both next() and __next__() for a class and making
one call the other would work, but I'm not sure we want to go that way.
> > 
> > > - 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!
> >
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches




More information about the anaconda-patches mailing list