LWN.net Logo

Musings on python by a fairly long-term user.

Musings on python by a fairly long-term user.

Posted Oct 18, 2008 17:14 UTC (Sat) by maney (subscriber, #12630)
In reply to: Fedora and long term support by Tet
Parent article: Fedora and long term support

You need to understand that I love Python - it's been my language of first choice for most things (viz., applications-level work) for years now. I mean, heck, Python saved my from PHP! <wink>

But the way the language changes - no, it's not so much that it changes that's a problem. At the language and base library level they really do a pretty good job of minimizing the necessity of writing backwards incompatible code. It's the way nearly everyone else doing Python library, framework, and application development seems unable to resist using every new feature the moment it becomes available, with little or no apparent consideration as to whether the benefit, as opposed to the shinyness, of doing so really should outweigh consideration for backwards compatibility.

The Django web framework is a blessed exception to this tendency, but alas it's an all too rare one. The typical Python project relies (at least in its actively developed trunk) on features available only in the very latest release of the langauge, even when they're merely syntactic sugar for something that's been easy enough to do for years; the typical Python project also lasts only a few years, if that, before becoming abandonware. Of course a lot of opensource projects go that way no matter the implementation language...

So anyway, before I wander further off track, I don't think a two year old version of a langauge is obsolete by any sane criteria. The language developers seem to agree - not only 2.4 but even 2.3 has had a minor version release this year. I think this churn is a real issue - it's not an original thought, but consider how beneficial the relative stagnation of the Perl language seems to have been for its adoption. A language really shouldn't be a source of frequent new shinyness - it's role is to be the platform on which you build stuff, and stability in that base platform is a real help to application developers, at least ones who need to deploy to more than a handful of boxes they keep in a froth of constant updates. Consider again Django - it's changed amazingly in the three years between the initial public release and its long overdue 1.0 release, but I believe it still works with Python 2.3, as was originally targeted as a goal. I know for a fact it runs under 2.4 just fine, though I can't speak to the vast majority of the third-party apps out there...


(Log in to post comments)

Musings on python by a fairly long-term user.

Posted Oct 21, 2008 0:19 UTC (Tue) by jamesh (guest, #1159) [Link]

Why do you think it is bad for a language to improve over time? Often language improvements let developers do things they couldn't do before or let them express things more concisely (which usually results in fewer bugs). It has managed to do this while maintaining good source level backward compatibility.

Python certainly isn't the only language to have seen improvements in recent years (generics in Java and C# come to mind).

What you seem to be complaining about is libraries and applications that have made use of these features without thought for compatibility with older versions of Python. There are a number of causes for this:

  1. The code can't be written without the feature.
  2. Not using the feature would result in significantly more verbose or more error prone code.
  3. The developer is not aware that the feature isn't available in older versions of Python.
  4. The developer does not consider compatibility with the old version important.

I can understand you being annoyed at the second two cases, but just as often it is one of the first two. When I was working on version 2.0 of PyGTK, I moved the minimum Python version requirement up from 1.5 to 2.2 because I needed the new class system introduced in that release. It caused some short term pain, but was the right thing to do. Similarly, Django uses the decorator syntax introduced in 2.4 to good effect, which cuts off support for 2.3.

At some point, the benefits of the new syntax just outweigh the downsides of requiring the newer version (where this point occurs depends heavily on what platforms you're targeting of course).

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds