Maybe it is time to move tools to Python 3.x?

Bohuslav Kabrda bkabrda at redhat.com
Fri Dec 5 12:24:05 UTC 2014


----- Original Message -----
> Hi,
> 
> On 12/05/2014 03:08 PM, Bohuslav Kabrda wrote:
> > ----- Original Message -----
> >> Hi,
> >>
> >> On 12/04/2014 02:30 AM, Matthew Miller wrote:
> >>> On Wed, Dec 03, 2014 at 08:13:42PM +0100, Marcin Juszkiewicz wrote:
> >>>> When I worked at Canonical there was a goal to move both internal and
> >>>> public tools to Python 3.x version. IIRC started somewhere around 12.04
> >>>> and today when you look at Ubuntu Touch you will not find Python 2.7
> >>>> there. Similar with other tools.
> >>>> Can it be done? Maybe not in a month but who knows - f22 cycle?
> >>>
> >>> Take a look at
> >>> <http://fedoraproject.org/wiki/Changes/Python_3_as_Default> for some
> >>> work in progress.
> >>>
> >> Since Marcin specifically mentioned tooling -- is there a separate place
> >> where we can document the coding issues involved? e.g. best practices
> >> (should we use python-six as a compatibility layer? etc.)
> > 
> > AFAIK there's not a Fedora specific place for best practises around py3
> > porting. I myself consider these resources great:
> > 
> > https://docs.python.org/dev/howto/pyporting.html (upstream docs on porting
> > Python code)
> > https://docs.python.org/3/howto/cporting.html (upstream docs on porting
> > Python C extension)
> > http://python3porting.com/ (a great reference for both C and Python
> > porting, including tons of examples)
> > http://www.wefearchange.org/2011/12/lessons-in-porting-to-python-3.html (a
> > blogpost on how python-dbus was ported, lots of great gotchas there)
> > http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/ (interesting
> > notes on work with unicode)
> > 
> > https://wiki.gnome.org/PyGObject/IntrospectionPorting (porting from PyGTK
> > to PyGObject Introspection)
> > http://overtag.dk/wordpress/2013/01/first-impressions-of-gtk3-migration-in-python/
> > (same as above)
> > 
> > From the tools/libraries that can be used:
> > - https://docs.python.org/3.4/library/2to3.html (package python3-tools) is
> > a tool that you run on your code in order to *move* it to Python 3 (e.g.
> > doesn't guarantee backwards compat)
> > - http://python-modernize.readthedocs.org/en/latest/ (package
> > python-modernize) - like 2to3, but tries to maintain backwards compat with
> > Python 2.6+
> > - https://pythonhosted.org/six/ (package python{,3}-six) - importable
> > library that helps write code compatible with both Python 2 and 3
> > 
> > And you can also have a look at my presentation from this year's Flock, it
> > speaks about basic differences, porting and how people can help with
> > porting:
> > https://bkabrda.fedorapeople.org/py3-as-default.pdf
> > 
> > Hope this helps!
> > 
> Thanks, it does. So it's up to each internal tool's maintainers to make
> them Python 3 compatible and then generate Python 3 subpackages (like
> python3-dnf), right?

Generally, yes, but there are two sides to this:
- assuming the package is a "tool" or "application", it should just be switched to Python 3 (e.g. fedpkg - users don't care which Python runtime it runs on, it's just fedpkg)
- assuming the package is also used as a library (or *is* library), it should provide python3-foo subpackage

As for DNF, I think it should provide python3-dnf binding along with python-dnf, but "dnf" command should just switch to python3 without users even knowing about it.

> Best regards,
> 
> --
> Michel Alexandre Salim
> Fedora Project Contributor: http://fedoraproject.org/
> 
> Email:  salimma at fedoraproject.org  | GPG key ID: A36A937A
> IDs:    keybase.io/michel-slm      | IRC: michel_slm at irc.freenode.net
> 
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments

-- 
Regards,
Slavek Kabrda


More information about the devel mailing list