Library support for Python 3.x

[Mike C. Fletcher]

Kevin Walzer wrote:
> I'm going to be starting some new Python projects in Python 2.6, but
> am concerned that at least three of the libraries I will be
> using--pycrypto, paramiko and feedparser--are not currently supported
> in Python 3.x. The authors of these programs have not given any
> indication that work is underway to support Python 3.x. Eventually I
> plan to migrate to Python 3.x.
>
> I don't want to be stuck using libraries that may not be updated for
> the next generation of Python. How are others handling this issue?
>
> --Kevin
Some of us are saying:

    * When Python 3.x has something compelling to offer:
          o Users will start asking for Python 3.x with a *reason* to
            justify the cost
          o Libraries will begin to see the pain of porting, and most
            importantly, *maintaining*, as a reasonable trade-off
          o Libraries will port (and maintain)
          o Applications should *then* port
    * or When everyone is already on a (basically) compatible 2.x
      version (i.e. 2.6+); say in 3 years:
          o Conversion and maintenance costs will lower to the point
            where we can justify them for libraries

Python 3.x has very little that is a compelling use-case (versus 2.x)
for most people I've talked to.  My paying customers aren't screaming
"we want to spend a week of your time to rewrite, re-test and re-deploy
our working code into Python 3.x so that it can do exactly the same
thing with no visible benefit and lots of likely subtle failures". 
Unicode-as-default doesn't really make customers say "wow" when all
their Unicode-needing code is already Unicode-using.  A few syntax
changes here and there... well, no, they certainly don't care (can't say
I *really* do either).  The initial marked slowdown for 3.0 (which I
gather should be mostly fixed in 3.1) didn't do much of a sales-job either.

Possible compelling arguments that would get people to convert (with the
projects working on them):

    * 5x (or more) speedup (PyPy, Unladen Swallow)
    * adaptive parallelization/execution-kernel mechanism as a
      first-class primitive (Apple's C extensions for OpenCL)
    * continuation-like mechanisms, anonymous code blocks a-la Ruby
      (PyPy, Stackless)
    * (free) threading, GIL removal (IronPython, Jython)
    * compilation-to-native (PyPy)
    * compilation to mobile-platform native (PyPy?)

None of those in in Python 3.x, though there's talk of merging Unladen
Swallow into CPython to provide a carrot for conversions (though AFAIK
it's not yet a 5x improvement across the board).  To compound the
problem, Python 3.x doesn't include any of the syntax changes you'd want
to see to support e.g. anonymous blocks, continuations, OpenCL
integration, etceteras... so if we want those, we're going to have to
either introduce new syntax (which is blocked) or hack it in... which we
could do on Python 2.x too.

I don't know about other maintainers, but I've started running PyOpenGL
tests with -3 on Python 2.6 to get a feel for how many issues are going
to come up.  Most have been minimal.  But when I sit down and actually
consider *maintaining* a 3.x release when I'm already *barely* able to
keep up with the 2.x maintenance in my tiny amounts of free time...
well... I do *that* stuff for *fun* after all, and double the headaches
for no noticeable benefit doesn't really sound like fun... oh, and numpy
isn't ported, so screw it ;) ...

Interestingly, at PyGTA Myles mentioned that he'd found his first-ever
Python 3.x-only library!  Which he then converted to Python 2.x, because
he actually wanted to use it in real code :) .

Projects which haven't ported to Python 3.x aren't necessarily dead,
they're just not nailed to that particular perch (yet),
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com