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 -- http://mail.python.org/mailman/listinfo/python-list