A nice podcast on Python VMs

I don't have much time and patience for podcasts and I'm really happy when I find one that doesn't make me feel like I'm wasting my time. Here's probably the most informative podcast on Python that I've listened to in a long time:

• How Python runs by Chris Hefele [MP3] (Guest podcast on Python411)
  

It's a nice high level overview of CPython, Jython, IronPython, Psyco and PyPy. How they came about, what's the idea behind each of them and how they relate to each other.

The podcast is from April and in my opinion paints a somewhat rosy picture of these technologies but it's still highly recommended.

Django, TurboGears, Pylons comparison

It doesn't even try to be "scientific" but I still found this comparison of the currently popular Python web frameworks very informative:

Unscientific and biased comparison of Django, Pylons, and TurboGears

Guido's Python 3000 Talk

I somehow missed this talk Guido gave at Google about Python 3000. I found it through StumbleUpon now.

Python web frameworks quote

Reading through the PyCon 2007 notes:

There are more Python frameworks than reserved Python keywords.

Funny because it's true. :)

PEP 8 checker

PEP 8 checker for the anal retentive in all of us. :)

/Users/gergely/twp/twp/bot.py:32:16: W291 trailing whitespace
    sys.exit(1)
               ^
    JCR: Trailing whitespace is superfluous.

/Users/gergely/twp/twp/bot.py:34:1: E302 expected 2 blank lines, found 1
def refresh_images(limit=dbbot._default_limit):
^
    Separate top-level function and class definitions with two blank lines.

    Method definitions inside a class are separated by a single blank line.

    Extra blank lines may be used (sparingly) to separate groups of related
    functions.  Blank lines may be omitted between a bunch of related
    one-liners (e.g. a set of dummy implementations).

    Use blank lines in functions, sparingly, to indicate logical sections.

I'm the kind of masochistic guy who actually enjoys this kind of thing, but I need to figure out a better way to integrate it with PyDev. I wonder what's the easiest way to make Eclipse jump to the line where the error happened. Hmm...

Rails / Django comparison

Found this on the Django mailing list. A nice Rails vs Django comparison.

I think there is one thing that both Rails and Django have over TurboGears: their main maintainers all use them to create web applications full-time, on a daily basis. I'm not sure whether this is true at all for TurboGears. But I'm still optimistic. The book is coming out real soon now and there is an ongoing effort to clean up the docs. The TurboGears users mailing list has 2300 subscribers vs. Django's 3300. A couple of month ago they were about the same. Hmm...

Django Book preview: a nicely done comment interface

I'm a card-carrying TurboGears fan but I also keep an eye on the Django framework. You can think of both as Python's response to Ruby on Rails.

The Django team released a public preview of the upcoming Django book recently and I got to say, that the comment interface is so nicely done (in Django of course), that I have an urge to stay there and keep commenting. :)

Extra points for releasing the book under a free license (GFDL). Many open source projects died or withered away slowly due to the lack of good documentation. It's good to see the bar being raised in this regard.

Update: It seems that they use Jack Slotum's way cool YAHOO.ext package. Ajaxian entry.

PyJamas: a Python GWT clone

Google Web Toolkit is an interesting idea: let's write all our web site logic in one programming language instead of 2. You write all your code in Java and the framework's black voodoo custom compiler generates client side JavaScript for you, which in theory you'll never have to see and more importantly never have to debug. An analysis of GWT deserves its own post but right now I'd actually like to talk its Python clone: PyJamas.

You can check out the web demo here: PyJamas KitchenSink.

I admit that I haven't yet had the time to play much with PyJamas, but I have a few theoretical reservations.

I don't think its hard to see why GWT has potential. JavaScript does have a somewhat deserved bad reputation. I learned to hate it back in 1998-2000 when I was a full time web developer working on sites that had to support all major browsers and lost a significant amount of hair while struggling with browser incompatibilities. Yes, times have changed and JavaScript/EcmaScript has come a long way, but it is still a pain in the neck when it comes to development and especially debugging. And as we all know, developers spend most of their time debugging.

Here's where Java comes in. It's strongly and statically typed, so the compiler can check all kinds of stupid mistakes. I notice how annoying it is when I switch to a dynamic language from Java that I don't find out about these until I actually run the code:

• wrong type or number of arguments when calling a method
• calling a non-existing method
• referring to a non-existing class
• missing imports
• etc.

All these can be due to typos, copy & paste errors or simple lack of caffeine. :) However when I'm developing in Eclipse the IDE -- actually it's embedded compiler -- catches them instantaneously. I don't have to fire up the server process and invoke it in a browser window. It all happens when I'm still typing the code. One has to admit that this saves a lot of time.

Since dynamic languages don't have the luxury of the compiler catching these simple problems, there is a much stronger motivation to write an extensive unit test harness, so that these basic errors don't eat up too much of the developer's interactive debugging time. Having a test harness is a good thing, but having to write tests for trivial stuff that the compiler could check is, well unproductive.

Now its a matter of debate exactly how much time is saved or wasted by declaring your types and relying on the compiler to do these checks or not declaring them and creating a test harness and relying on shorter turnaround times instead.

Going back to PyJamas, I believe the problem is that Python and JavaScript are not different enough to have a significant productivity gain when you're writing and debugging Python code vs. JavaScript. All the silly mistakes will have to be caught at runtime.

I'm still looking forward to trying it out though since there is a good chance that I'm completely missing the point. :)