My Vision of Python 3000 — Back To Basics

Let’s just get a little bit of a disclaimer out of the way – I don’t know everything. I tell my wife that I do, but I’m not sure she’s really pretending her hardest to believe me. Designing and developing a programming language is a hard job, and I’m certainly no expert in the field. I am extremely thankful for the many years of hard work that the Python development team has put into Python. In my humble opinion, Python is the greatest computer programming language in existence.

Now please, stop developing Python. Put down your keyboards, and walk away.

Well, I don’t really mean that. Not in the literal sense, anyways. If everyone put down their keyboards and walked away, they might find their way outside where they might get sunburnt. Then they would try to remember who told them to go outside and get sunburnt, and suddenly I would have a class-action lawsuit to deal with. I would have to retain a legal team at an extreme expense to defend myself. I don’t have a extreme cash to expense, so don’t put down your keyboards, don’t walk away, and don’t sue me.

Python the language is complete. It doesn’t need any more features.

Let me define “need” for you — that feeling you get when you know something will be missed in the first two minutes of looking at a new programming language. Alright, I admit it, it’s a crappy definition of “need”. But it’ll do.

I did not need the builtin function reversed(). If it had it been included in the standard library, I would have been happy.

I did not need the builtin set types. They already were included in the standard library. Adding them to the language as a new type was not necessary.

I did not need generator expressions. I could have just written a generator function.

I do not need a “with” statement. I can use a short variable name.

The difficulty comes with defining which syntax options are worth including in the language itself. For example, I can add two numbers with the expression “x – (-y)”, but I think most rational people would agree that “x + y” is a better choice. Sometimes adding language syntax could provide a new and powerful expressive tool. When do you draw the line? I’m drawing the line at Python 2.4. That far, no further.

New builtin functions? Don’t bother, please. Put them into a library. Adding a new builtin function means that I need an updated vim syntax colouring file. It means my namespace is just a touch more polluted. It’s just not necessary.

CPython the Python interpreter probably isn’t complete. It keeps getting faster and better the more people work on it. We all like you CPython! Chin up!

Python’s documentation is a good effort. Writing documentation is hard, thankless work. Python documentation writers deserve a pat on the back. But it’s a job that is not “done”.

New users have difficulty finding some very specific parts of the documentation. For example, section of the Python library reference is “String Methods”. This isn’t even on the library reference’s table of contents, since it is buried one level too deep, yet it is likely one of the first few pages people need. The same is true for section (String Formatting Operations) and section (Mutable Sequence Types). The entire section 2.3, builtin types, is one of the most important references for Python. It is where many people will start – how do I read a file, how do I manipulate a string or an array? Yet some Python programmers don’t even find it.

Want to get a little more complex? How about creating a class that acts like a dictionary? You’ll probably need section 3.3 (Special Methods) of the Python reference manual. Can someone please take this section, create a list of all the special method names, and hyperlink them to the appropriate description of what they are?

The Python documentation has good content. I believe that finding what you’re looking for is the hard part.

Python’s standard library has a fork in the road, ahead.

I want to say that the standard library should include everything. It would make it easier to work with new python software if it had no dependencies though, right? If the Python standard library pulled more and more software into it, it would be very easy to build new software. Need a widgetly? Use the widgetly module. Need a foogleblarg? It’s in the foogle package. But this isn’t practical. The widgetly people need a different release schedule than the foogle package. foogle needs to put out an emergency patch to fix a security hole, but there’s no Python release planned so it doesn’t get out to people.

So then there’s the middle road, that the standard library is traveling on now. Need the ‘socket’ module? It’s included in Python. Need some XML parsing? Got that too. Need a bit more XML parsing? You’ve passed the line, you better download PyXML. CGI, yes; FastCGI, no; regular expressions, yes; python image library, no. Everyone has their own vision of what should be included, and what shouldn’t be.

I think the third road here lies with distutils and the “.egg” package format. If this can make it so that dependant packages of appropriate versions are automatically downloaded, compiled, and installed… then Python doesn’t need a standard library. Every module of importance could be distributed and maintained separately from Python. Modules can still be maintained and developed by the Python developers, but until a programmer or another piece of software needs the sndhdr module it isn’t installed.

I’m not being critical that much. But I don’t like the way Python 3000 planning seems to be going. I’m not into language changes. Python is pretty darn great the way it is – that’s why I like it.

Be Sociable, Share!

11 Comments on My Vision of Python 3000 — Back To Basics

  1. Lawrence Oluyede
    2006/07/17 at 2:24 pm (11 years ago)

    Let me say what I think:
    – generator expression are useful like list comprehension are. It’s not a matter of syntax because instead of [] you use (). That’s it.
    – with is not for shortening. with is a pattern. with is there to auto-close resources and so on. with is like C# using, not VB6 With

    Despite these things I’m mostly agree with your point 🙂

  2. Mathieu Fenniak
    2006/07/17 at 2:31 pm (11 years ago)

    Lawrence, thanks for your feedback.

    I consider generator expressions to be “new syntax” because code written with them cannot be parsed by an earlier version of the Python compiler. Of course generator expressions are useful, just as list comprehensions are. But I don’t consider them to be necessary.

    “with” being like C#’s “using” is better than being like VB’s “with”. But I’d still be quite happy programming in Python without it. If I know that a resource needs to be closed (which one assumes I must know if I chose to put it in a ‘with’), then I’m quite content to have to call the close method on that object.

  3. David Goodger
    2006/07/17 at 3:01 pm (11 years ago)

    There have been people saying this since Python 1.5, and probably earlier.
    If Guido and the python-dev team thought this way, Python would be a dead language.
    Anyone who thinks Python version X.Y is complete has an option (for their own code, at least): don’t upgrade.
    When you’re in the very-high-level open source programming language business, it’s evolve or die.

  4. Pete
    2006/07/17 at 3:59 pm (11 years ago)

    I can’t agree with most of these points. It sounds like you’ve been following the Python 3k discussion, so you already know that the point is not brand new features, but more of a chance to drop support for things that should be dropped.

    You mention how all users have their own needs for the standard library, but the same is true for some of the new features in the python language. Just as nobody benefits from all parts of the standard library, nobody will benefit from all language features.

    The point is that there are problems out there, especially as people push computers and languages into new domains. Several of the new features you say you don’t care about or need are going to be big wins for me and the code that I write.

    I can’t wait for the new 2.5 features to help out my code. Looking forward to 2.6.

  5. Bob Ippolito
    2006/07/17 at 4:45 pm (11 years ago)

    I’m going to have to agree with Pete and David here. If CPython weren’t adapting to problems that people are trying to solve, then it would fade away. I’d certainly switch to something else pretty quickly if it were stagnant.

    I don’t know what kind of code you write, but lots of code would be better off (as in shorter and more correct) with the “with” statement. Perhaps you just don’t understand what it’s for.

    Also, what the heck does this have to do with Python 3000? The majority of the 3000 effort is to make the language smaller and more consistent… throwing out deprecated stuff that 2.x needs to keep for compatibility.

  6. Cliff Wells
    2006/07/31 at 12:33 pm (11 years ago)

    I actually have the opposite viewpoint, and yet agree in a rather backwards way: I think Python is too stagnant and yet at the same time, feel that the “features” being added recently are mostly cruft to cover up basic lacking in the language.

    I’ve recently come to appreciate the elegance and power expression-based languages (Ruby, Lisp) give their users, and the artificial distinction between statements and expressions in Python has begun to frustrate me.

    One of the mottos of Python is that “practicality beats purity”. The part of me that wants to earn a living certainly agrees with this point. However, the part of me that loves to code disagrees vehemently. I’ve noticed an overall trend in Python (list comprehensions, decorators, the upcoming ternary operator) to add features that give you some, but not all of the power of an expression-based language. This cruft adds to the size of the language and the amount of syntax and special cases a programmer must hold in his head (that’s where I agree with Mathieu). At the same time, they fail to deliver a fraction of the power that *removing* a “feature” of the language would.

    If I had one wish for Python 3000, it would be to see the arbitrary distinction between statements and expressions removed. I think this could be done in a mostly backwards-compatible way and would improve both the consistency and expressiveness of Python tremendously. And as a side benefit, we could lose a lot of other language “features” that have been crufted on to compensate for this shortcoming.

    A short time playing with Logix has convinced me that Python has one foot set squarely in the grave at this point. I know plenty of people who have moved to Ruby from Python and yet know of *nobody* migrating the other way. Most of the ones whom I’ve asked about it cite features such as anonymous code blocks and overall expressiveness (Rails, of course, being another reason, but I think our web framework guys have this in hand). I think that should be a loud and clear alarm in the Python camp. If Python became expression-based it would be far superior to Ruby in every way. I expect Ruby will inspire more (and better) expression-based languages and Python will start to look more and more like FORTRAN with its inflexible statement-oriented syntax.

    So yes, I’d like to see Python made simpler, but most definitely let’s not let it stagnate.

  7. Khebab
    2006/09/21 at 7:04 am (10 years ago)

    Hi there,

    I’m a Python newbie and I’m wondering what edition of Python I should install: ActiveState Python or Python Enthought?


  8. Mathieu Fenniak
    2006/09/21 at 7:15 am (10 years ago)

    Hi Khebab,

    I’ve always been a fan of the standard Python distribution from It can be enhanced for the Windows environment by downloading pywin32 as well.

  9. khebab
    2006/09/21 at 8:13 am (10 years ago)

    Thanks for the quick response!

    Last question: Python Enthought seems to come with a lot of scientific packages (SciPy, PIL, etc.), is it the case for the ActiveState package? are those packages compatible between editions?

  10. Mathieu Fenniak
    2006/09/21 at 8:19 am (10 years ago)

    As far as I know, all those packages should be quite compatible with either distribution of Python.

1Pingbacks & Trackbacks on My Vision of Python 3000 — Back To Basics

  1. […] In my last post, I kinda ranted about python development. I thought that I was being constructive and presenting a well thought out point-of-view, but it wasn’t really. There were probably some ideas in there somewhere, but I forgot a couple important actions in writing. I did not research the topic of Python 3000 very well, and I did not think about rational reactions to my “arguments”. […]