July 2006 archive

Vancouver Python Workshop

My friend Bradley is putting on a talk at “VanPy” entitled “Rapid Development of Enterprise-Level Web Applications”. It is going to be an interesting case study of a large web application that was re-developed in Python over a couple of years. The application went from ASP and Windows based to Python and Linux – yay! For anyone who has never see a Python talk that has to do with an Oracle database (*gasp – not MySQL? ;-) *), and terabytes of data, this is your chance.

Hopefully Jim Hugunin’s IronPython talk won’t steal too much of the potential audience away.

I’ll be the rude guy in the back of the room making silly faces.

Ever want to unwrite something?

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”.

I think that I was wrong.

If you didn’t read it, the just of the post was that development of the Python language should stop. The real reason I felt this way is because I’ve been reading about Perl 6 lately. I love Python, and I was scared to think of it going down the same road. Since then, I’ve thought about language development in general, and I’ve watched a presentation by Guido about Python 3000 (which I will probably see again this weekend at “VanPy”).

Programming languages do need to develop and evolve. Mistakes are made, new alternatives are developed, and things need to be fixed. Python 2.4 is a better environment for developing software than Python 1.5 was, and Python should continue to improve. There will likely be some growing pains. Maybe a feature I like will get chopped from the language. But it’s not the end of the world. I look forward to seeing the future of Python – don’t ever go Perl 6 on me, please.

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 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.