Upgrade

It’s been too long since I’ve written a non-trivial amount of Python and for the last couple of days I’ve been spending some time to look around and see what got better and what still sucks in Python land. The good news is that a lot of things have gotten better, including the language itself. Sadly, Python is still missing a clean way to represent enclosed scope, which seems totally out of kilter for a language that is otherwise so dynamic. Sure, you return a named throw-away function from another function in order to generate a closure, but you can’t create an anonymous variant of the same thing. Also, Python’s lambda function is still crippled, to my great chagrin. JavaScript’s function and Ruby’s blocks still have Python by the balls on this one.

Also, I’m not sold on decorators. The burgeoning catastrophe that is Java 5 annotations should be an object lesson, but I’m afraid good taste hasn’t prevailed in either language yet. But whatever quibbles I might have with various syntactic forms in modern Python, it’s still the best thing going. Idiomatic Python remains readable, audit-able, and fast.

Here’s the short list of the toolchain I’m assembling for an upcoming project:

While the greenlet project looks like an interesting alternative to Twisted, it doesn’t look “baked” enough to handle most of the situations I’ll be relying on Twisted for. In much the same way that library depth is the only reason I keep inflicting Java on myself, protocol implementation breadth and depth are the reasons that Twisted probably has very long legs, despite the kludgyness of requiring factory classes every time you want to sneeze.

I’m tremendously excited about lxml. It implements the ElementTree API but extends it with all kinds of XPath and XSLT goodies that make doing XML in Python much less painful than the cluster-fuck that is 4suite and PyXML. Our long XML processing nightmare may finally be over, no surprise, thanks to libxml/libxslt.

Is there anything that I’ve totally missed in the last 2+ years of Python development that I shouldn’t be going without?

10 Comments

  1. Posted June 13, 2006 at 7:27 am | Permalink

    lxml does indeed look pretty cool. Python 2.5 includes ElementTree, which means that lxml will be an easy step up for people who need full XPath and XSLT.

    One thing worth correcting: Python doesn’t have annotations in the sense that Java has annotations. Python has “decorators”, and the difference is quite significant.

    (This code is likely to get mangled, but hopefully the point will still get through):

    @expose()
    def foo(self):
    return “Bar”

    may look like it’s annotating foo as being available for the web (in TurboGears/CherryPy). But, it is in fact exactly equivalent to:

    def foo(self):
    return “Bar”
    foo = expose()(foo)

    A decorator doesn’t just add metadata. It can completely replace the original function. It’s a powerful and relatively easy way to deal with cross-cutting concerns.

  2. Posted June 13, 2006 at 7:35 am | Permalink

    Hey Kevin,

    You’re right, of course. Although I will say that I dislike *both* annotation and decorators. Of the two, I do prefer Python’s approach, but both are a bit too “magical” for my tastes.

    Thanks for catching my error.

    Regards

  3. Posted June 13, 2006 at 8:17 am | Permalink

    Hi Alex,

    Everyone’s tastes do vary… I actually find decorators to be no more magical than inheritance. It’s just a different construct and a different way to encapsulate code. Consider this example to see where it’s valuable:

    def foo(self):
    trans = start_transaction()
    try:
    …do stuff…
    trans.commit()
    except:
    trans.rollback()
    trans.end()

    That gets old pretty quickly. One way around it is this:

    def foo(self):
    def dostuff():
    …do stuff…
    run_with_transaction(dostuff)

    (of course, you’d be able to use an anonymous block for this in a language that supports that :)

    But, to me, the decorator style is quite nice:

    @use_transaction()
    def foo(self):
    …do stuff…

  4. Posted June 13, 2006 at 8:27 am | Permalink

    Django is pretty A for a lot of web stuff but I guess you already knew that.

    I have never been completely happy about database access in Python. I could live with SQLobject and Django’s models are kind of nice but it was always missing some oomph.
    Recently I have been hearing all kind of nice things about SQLalchemy(.org) which indeed looks very promising.

  5. Posted June 13, 2006 at 9:04 am | Permalink

    I would also have suggested TurboGears, following my natural biases, but I know the kind of stuff that Alex works on and Twisted is likely the best choice for that.

    SQLAlchemy is indeed quite impressive and is destined to be the standard in TurboGears. Most relevant to Alex, it’s worth noting that some work has been done to integrate SQLAlchemy with Twisted.

  6. Posted June 14, 2006 at 7:49 am | Permalink

    If you’re interested in generic functions, PJE has an implementation (RuleDispatch) that’s slowly diffusing into a number of other projects.

  7. Posted June 15, 2006 at 2:20 pm | Permalink

    Sounds like a fun project :-)

  8. Posted June 15, 2006 at 10:44 pm | Permalink

    Hi, Alex,

    I’m the founder of ajaxcn.org, a Chinese Ajax website. There are many developers in China who are interested in in dojo toolkit. So we want to translate the dojo documents into Chinese.

    The documents we want to translate includes:
    http://dojotoolkit.org/docs/
    http://manual.dojotoolkit.org/

    Would you mind us to translate these documents into Chinese?

    Best Regards
    dlee.cn@gmail.com

  9. Posted June 19, 2006 at 12:02 pm | Permalink

    Hey David,

    We’d love your help with the docs and with internationalizing/localizing the toolkit’s built-in strings. Send me private mail so I can get you on the dojo contributors mailing list.

    Regards

  10. Posted July 2, 2006 at 7:29 pm | Permalink

    Hi, alex,
    I sent an email to this mailbox: alex@dojotoolkit.org, please check your email.

    Best Regards