IP Street’s application runs on Python 2.7. Earlier this week, I evaluated all our Python packages for Python 3 support, as the first step in deciding when to migrate our codebase.
Although this was the time I’ve checked our packages for Python 3 support, I expected Django to be the only one that didn’t officially support it. (Production support is slated for version 1.6, which is now in release-candidate.) But Django is the only project whose development roadmap I closely follow! D’oh! Talk about a blind spot!!
This is why it’s good to sit down and formally check each package. Make a list of every package and check each one…
Of the 29 packages we use, 20 (69%) support Python 3 and nine (31%) do not. The nine packages are:
- django. Python 3 support was “experimental” in version 1.5, and is production-quality in version 1.6, which is imminent.
- django-guardian. The documentation doesn’t explicitly say “supported in Python 3.” OTOH, it has closed Python 3 tickets, is under active development, and Django 1.6 is just over the horizon. I’m guessing/hoping this supports Python 3 shortly after Django 1.6 releases.
- django-mobile. Its PyPI page explicitly lists support for Python 2.6 and 2.7, but not 3. Hmm. The last check-in was five months ago. OTOH, it isn’t a lot of code, so I could fork it easily enough.
- nltk. This is surprising. I would have expected a major package like this to already support Python 3. Support is in NLTK 3.0 alpha, which is available now — but it’s Alpha. I just need to wait for NLTK 3.0 to release…
- fabric. Another surprise. The PyPI page lists support of only up to Python 2.6. Odd.
- paradox. This has the least obvious status of all our packages. The last check-in was a year ago. Ehh…I might have to replace it.
- paramiko. The good news is, there’s an active open Python 3 ticket.
- pyrax. Python 3 support is on their radar. I’m very impressed with the renewed support Rackspace is putting into pyrax. I’ll just be patient.
- flower. There’s an open ticket for Python 3 that already has some action.
I could fork, or work around, one or two of the smaller packages, if that’s all that stood between our codebase and Python 3. But I won’t do that, since NLTK, fabric, and pyrax aren’t there yet. It’s probably the right time to start planning our codebase changes, though.
I’ll check again in three months. Who wants to bet that Django 1.6 will be a big forcing function?
Seek Nuance 
Reblogged this on josephdung.
Hey John. As far as pyrax Python 3 support goes, it’s mostly dependent on our two OpenStack dependencies: novaclient and swiftclient. The pyrax.cloudservers and pyrax.cloudfiles objects are just super thin wrappers around those nova and swift clients, respectively. I have most of swiftclient ported, but it’s a tough time to get reviews due to the recent rush into the OpenStack release, and now the rush up to the OpenStack Summit. Other than those two, I believe all of our other dependencies are ported, and porting pyrax itself would be trivial.