Rails is the best thing that ever happened to Python (and Django!)

For what it’s worth, I agree whole-heartedly with Antonio’s post. Monitoring the Django community, we see so many people who come to, and love Django via the Ruby on Rails path. A lot of people are drawn into the RoR hype and for whatever reason they find that their skills, minds, or work patterns just don’t mesh up with how it works. Those people typically find their way to Django and some have even become valuable members of the community.

Rails is the best thing that ever happened to Python

Don’t let this confuse you though. Python (and Django) are able to benefit from all the interest geared towards dynamic languages, only because they are technically excellent and make a strong case on their own. Their communities are much less about marketing and more about substance, in my opinion. I understand those who go from Ruby to Python, but there are far fewer motivations in favor of a switch from Python to Ruby.

The reason for this is that, in a way, Python is currently an answer to Ruby’s MRI shortcomings. When I speak about Ruby’s shortcomings I always refer to the implementation and not to the design of the language, which is a well balanced and coherent mix of paradigms and features.

Python 2.6a1 and 3.0a3

Python 2.6 doesn’t bring a huge list of changes to our lives, but there is a substantial number of standard library modules which will now be officially deprecated. Most of these are pretty arcane, but two that may still be in wide use are the md5 and sha modules. These have been deprecated in the documentation for a while now, and you should be making the transition to using hashlib if you plan on moving forward with your Python interpreter.

Perhaps one of the saddest moves is the removal of gopherlib from the standard library. Lets have a moment of silence.

A number of Python 3.0 incompatible commands now throw warnings if you attempt to use them:

apply, callable, coerce, dict.has_key, execfile, reduce, reload

A number of email-related modules will gain DeprecationWarnings (i.e. mimetools, rfc822, multifile, et cetera). There may possibly be a number of new items added to the standard library:

• winerror
• JSON implementation (whoa)
• setuptools

Check out PEP 361 for the whole low-down on what’s coming in 2.6.RELEASED Python 2.6a1 and 3.0a3

On behalf of the Python development team and the Python community, I’m happy to announce the first alpha release of Python 2.6, and the third alpha release of Python 3.0.Python 2.6 is not only the next advancement in the Python 2 series, it is also a transitionary release, helping developers begin to prepare their code for Python 3.0. As such, many features are being
backported from Python 3.0 to 2.6. It makes sense to release both versions in at the same time, the precedence for this having been set with the Python 1.6 and 2.0 releases.

Speaking of Pownce

The team over at Pownce (just Leah Culver? I’m not sure they ever hired a second developer) has finally released their full API!

The new API uses oAuth for the authentication portion and adds the ability for any developer to recreate a fully-capable Pownce application. The old version one API only let you pull down yours and friends updates, but not post messages, links, events, or files.

There were unofficialy ways to do this of course (I even helped reverse engineer the old protocll), but it’s great to have an officially sanctioned method to do this.

I’ve got a personal Pownce account that I don’t use very much. Perhaps the new applications to be built on this new API will help me use it more often.

As for my personal projects that I’d like to add Pownce too, I just have to wait for Mike Taylor or James Bennett to completely re-engineer their old API implementations!