Recently, I started to really jump into learning Python. I'd been interested in it before; the live interpreter was awfully handy and it seemed like another good language to pick up. For whatever reason, I wrote a couple trivial programs in it and never really got back into it until a few months ago. Since then, I've wound up rewriting a couple Perl + shell scripts in the language and really liking it a lot. What follows are my impressions after trying the language out for a little while.The Good
Python is really
easy to learn, almost stupidly so. Much like my early days with BASIC on an Apple II, I can jump right in and try new things in the interpreter to see if they work as planned. This interpreter is also a very nice way to play with and test a half-complete script in pieces before letting the whole thing run, which is terribly handy.
Overall, Python seems to go out of its way to be really helpful; even if you don't have documentation handy, it isn't difficult to dissect a module and figure out how you can use it thanks to the
keywords. Most documentation I've run into is surprisingly useful -- informative without being stupidly verbose.
Speaking of being verbose, I can't help but draw some comparisons to Java here. Python is certainly object-oriented, much like Java and C++ but it lacks those languages' distinction of being wordy and obnoxious. Yes, lots of things are objects, but you really don't notice unless you want to. Python doesn't seem to care
what paradigm you use when programming.
I've also noticed that the various libraries available in Python are really helpful; tools like Mark Pilgrim's Feedparser make handling RSS and Atom a fucking breeze. You give it either a url or a file name and it figures out what you mean on its own and parses it into a homogeneous data structure. This saves me a lot of time compared to poorly-maintained junk like
or some of the other XML parsing tools out there. This seems largely prevalent in the community as a whole; APIs are ridiculously easy to use I've found. pyAudere is another example; in roughly three lines of code, I can have a sound card initialized, an audio file (most formats supported, and it'll figure out what you mean on its own) loaded into RAM, and played back. I don't know that I've replicated such a feat with other tools.
Which brings me to something else I've really liked; the functional programming primitives that are readily available in Python. Tools like
and of course
are all just sitting there waiting to be utilized. These are awfully useful if you're hacking at Project Euler
for fun, but quite handy for more typical usage.
As a new user of the language, I don't think that I can escape commenting on whitespace. For the most part, Python's whitespace rules are exactly what you should already be doing in the first place
and as such I don't really see them as an issue. Lately, I wish that Java had a similar mechanism for when I have to read other people's code. The Bad
Python is constantly evolving. Right now, there are two major branches of the language, the Python 2 version family and Python 3. Within Python 2, there seem to be three significant versions (2.4, 2.5, and 2.6). Here's where the fun begins; I wrote a program on my netbook which had Python 2.6 installed as that version seems to be both current and well-supported by major libraries. Python 3 has some nifty changes, but it seems that a good number of libraries don't support it yet. This will undoubtedly change in time, but right now I only play with Python 3 a little bit and tend not to use it for anything I'm trying to really work on.
Normally when there's multiple versions of a language, it would seem a simple task to just avoid other versions. I did however bump into issues with this, and while it isn't Python's fault, it is annoying. I wrote a script on my netbook, tested it and everything, only to have it crash when I ran it on the Debian box at home. The problem? I was using a string formatting method that wasn't supported in 2.4 (the default version on the system) but was most certainly present on the copy of 2.6 on my portable machine.
I'm also not a fan of how bugs just seem to lie in wait with Python scripts. Because Python scripts don't get compiled at runtime like Perl, I've been bitten by the occasional bug hiding down an obscure branch of a program, such as a syntax error or type mismatch that I never noticed before. Being new to the language, I often make late discoveries about things returned by objects, or member functions that are apparently missing in today's version of the language. This is highly irritating to me.
While I haven't run into this, I have heard tales of poorly-behaved editors in collborative projects utterly wrecking a script because one was using tabs and another turned the tabs into spaces (and so on). It's a little alarming to me that an editor can break a build that badly, but this isn't something I've run into in practice.The Ugly
That multiple versions problem I mentioned? It can rapidly escalate into its own special world of pain and suffering. Again, this isn't really
a problem that I pin on Python's tail, but it has been a bit of a headache. While downloading and building a version of the Python interpreter isn't an arduous project, it seems that the standard library isn't assembled for you in the process. My current installation of 2.6 on Debian 5 is halfway braindead because at no point in the configure script did it bother stopping to say, "hey, you need a current version of
for this to work!" or anything like that. Even better, the instructions supplied when I attempted to
these things were not accurate. I think
I know how to fix it, but I'm bothered that this should be an issue. Oh well, it could be worse; evidently there's problems getting it to build at all on OSX 10.6. Conclusions
I'm really liking Python as a tool, and have barely looked back at Perl for the most part. I like Perl regular expressions better and how they just flow into the code as opposed to Python's
module, but that's mostly an issue of culture shock for me. Otherwise, I'm finding that a lot of my projects just work better, and seem to do so with less work on my part, which is really the important thing.
Labels: code, python