Python 3 and Growth (or the lack thereof)

Paul Bissex just posted a simple three-step procedure for how one might become acquainted with the changes coming in Python 3 (née Python 3000). The mere mention of Python 3 prompted me to start writing a comment for Paul’s post, but it went on long enough that I figured it wiser to post here.

In understanding Python 3, I think it’s equally important (especially for those of us who might not walk on the beaten path with regard to domains, types of apps, etc) to review PEP 3099, which outlines what won’t be included in Python 3.

Personally, reading PEPs 3099 and 3100 (which Paul references in his post) is depressing. I’ll explain why by example and contrast. Consider this post from GvR from about a year ago:

But please save your breath. Programmable syntax is not in Python’s future — or at least it’s not for Python 3000. The problem IMO is that everybody will abuse it to define their own language. And the problem with that is that it will fracture the Python community because nobody can read each other’s code any more.

This is predictable, especially given GvR’s prior comments on various topics surrounding more “esoteric” features like multiline anonymous functions, operator overloading, etc., etc., etc. However, compare and contrast that to this slideshow from Ruby’s Matz from about two years ago. I don’t have a money quote, but the difference in attitude and approach is staggering. There’s a line in Annie Hall (I think, or some other Woody Allen movie) where Woody’s character says that relationships are like sharks: they must continue to move forward in order to survive.

Now, I’m not saying that Python is dying somehow — far from it. However, I think it’s safe to say that it has stopped growing (and hasn’t grown significantly since v2.2 with the great class/type unification). Meanwhile, Ruby is “a white-hot nexus of innovation”, according to Tim Bray, anyway; and really, anyone who knows and cares about what Python is lacking in terms of expressiveness and capability would agree.

At this point, you might fairly assume that I’m some kind of Ruby booster, but in fact, about 90% of the coding I do these days is in Python, and that has been the case for almost 3 years. And as much as I enjoy working in Python, it has not (and looks like it will not) grow along with the problems that I need to solve.

Part II: The feedback to this post has been significant, both in comments here, on reddit, by email, and elsewhere on the net. You can read my summary follow up here.

12 thoughts on “Python 3 and Growth (or the lack thereof)

  1. Wow, having spent five minutes reading through PEP 3099 (which I hadn’t seen before), and weighing that five minutes against the time I might have spent following the thrashes in real-time on python-dev (but didn’t), I feel like I’ve been given an extra month of life!

    But it is a little grim, I agree. Just a little.

    1. I forced myself to unsubscribe from python-dev some months back when I realized that Python and I were on different paths. So many times, I had knocked out a paragraph or so of rebuttal to some decision, but then realized (thankfully in time!) that I wasn’t a contributor, didn’t know the source, and would simply be pissing into the wind that I still continue to reap. Mixed metaphors there, but you get my drift.

      I don’t really think it’s that grim in an absolute sense. Python is still going to kick butt for years to come in a variety of fields; web programming, hard science, misc. research, etc. will keep it going strong for a long, long time. And, for those of us who look to deliver value outside of Python strongholds, there’s tons of innovations and innovative languages and platforms elsewhere.

  2. Python is not pupating, like Perl is – When Perl 6 materializes, or if, it will be substantially different from Perl 5. Moth or butterfly?
    Python is merely shedding its skin. removing all the little parasites of inconsistencies that could make it sick and allowing room for new growth. Now do you think Python is just a little tiddler at the moment with huge growth potential, or already an eight-footer?

    1. I think Python could be and do amazing things. However, that’s not up to me, unless I were to become a full-time Python hacker (and even then, the most well-respected Python hackers aren’t GvR). “Huge growth” almost always requires breaking stuff from the past — and in this case, breaking founding principles as well. This is especially true with Python’s adherence to the principle of There’s Only One Way To Do It — the finest examples of metaprogramming facilities always exhibit the opposite, which is a sign of expressiveness and flexibility. (Of course, if one makes a few “bad” decisions, expressiveness and flexibility can lead to line noise. It’s a fine balance; I do not envy language designers.)

  3. I find it a good thing that Python is not going to change much. When looking to do real work, I look for a few things. The first and foremost is readability, I don’t want to spend all day reverse engineering someone else’s code. After I move on, my replacement should be able to read my code. While magic is fun, try being the one who has to decipher it.

  4. Why do you think languages need to continuously grow new features? Take the current DSL hype as an example: a lot of it is just people who don’t know how to write their own parsers and want to use their favourite programming language’s parser to prop up their back-of-the-napkin notion of what they should be writing instead of the boilerplate they’d otherwise need to write, all whilst ignoring existing languages designed for the very same purposes. Although I don’t doubt that good parser integration with a runtime system would be nice, a lot of the DSL-happy people just want to be able to capitalise on syntactic and semantic side-effects of their favourite language, calling for conveniences that a language designer should resist. (And they could all go off and play with Lisp anyway, right?)

    It has undoubtedly been said that good designers know that leaving features out can be more important than putting features in. Looking at that Ruby slideshow, one can but wonder whether, after adding things already in Python but then overshooting to include all sorts of other one-off conveniences, Matz will be as conservative as GvR supposedly is today.

  5. to me, i think whats “hot” in a language is when it stops adding new syntaxes and tricks, continues to remove its older and less-polished paradigms and converges on a limited set of absolutely perfect constructs from which I can express anything. Python was exactly the language that had this characteristic which is why I chose it.

    if you need a constant flow of newly released syntactic sugars and meta-trickery in order to feel like a language will allow you to “solve a problem”, that sounds like a need for fewer silver bullets and more target practice.

  6. As fun as new language features are, I think the useful innovations come in the form of new libraries. Nice syntax makes my job more pleasant, but it is the libraries which actually help productivity.

  7. Um, so you don’t think the “with” statement and coroutines were new features?

    What about the new metaclass hook that’ll be in Python 3.0 (and maybe 2.6)? It’s actually a pretty significant step forward for implementing Ruby-like DSL’s in Python.

    Meanwhile, if somebody could come up with a Python-like way of implementing blocks, Guido might actually go with it. It’s just that at this point, he doesn’t want bike-shed discussions about it, or assertions that it must be possible to have such a syntax, as he’s convinced that it’s not possible/practical. Someone would have to come up with a concrete proposal that perhaps handles the problem in an entirely new way.

  8. Python is not growing because you want programmable syntax and “esoteric” features? Features that 99% of software developers should never use. Let me guess, you have never maintained a project written in a language that supports programmable syntax where geniuses abuse meta-programming where simpler alternatives achieve the same goal.

    Python has areas it can grow in (e.g performance, better memory management, better profiling/diagnostic tools, unified/consistent library, smarter virtual machine (see PyPy), cruft removal, better/easier extension development in C/C++, etc), but adding new abstractions or syntatic sugar that one in one million programmers know how and when to use is not an area that deserves Python’s attention. We have Ruby and Perl for that.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s