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 2.3.6.1 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 2.3.6.2 (String Formatting Operations) and section 2.3.6.4 (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.
*), and terabytes of data, this is your chance.