Tuesday, May 31, 2005

How well do you know Python, part 7

Given the following two classes,

class A:
    def foo(self):
        print self.__class__.__name__

class B:

why does this work,

def bar(self):
    print self.__class__.__name__

B.foo = bar
b = B()

while this does not?

B.foo = A.foo
b = B()

Tuesday, May 24, 2005

Utah Python User Group

The former Provo-Orem Python Meetup Group is now the Utah Python User Group. I've set up a rudimentary website and discussion list; anyone interested in Python is welcome to join the list and/or attend the monthly meetings (next one on June 9th). (We're already on the user group wiki in case utahpython.org is hard to remember. :)

Friday, May 20, 2005

Spyce 2.0.1 released

Spyce 2.0.1 is available over at the usual place.

This is a bugfix release. Changelog:

    use tempfile.gettempdir() as default config.tmp
    add originalsyspath to spyceconf
    bugfixes for Active Tag compiler
    portability & other bugfixes (John Reese)

Demos working again on sf.net

SF changed the web space over to read-only. I updated the Spyce install to use the /tmp/persistent space and things are working again.

Thursday, May 19, 2005

Spyce vs ASP.NET

A former co-worker asked me over IM,

What advantage, other than being able to use it on a Linux box, does [Spyce] have over the ASP.NET Model? Because I can tell you, with Visual Studio, I feel pretty productive.

I answered,

The main one is a significantly shallower learning curve. Once you know how the ASP.NET event model and page lifecyle work, you are set -- but you remember how "easy" that was for [our] students. With Spyce there is only one rule: handlers run before the rest of the page, in the order they were added. That's it.

And, of course, Spyce runs Python. This is significant: Python is addictive; once you start writing code in it, it's painful to use less-expressive languages. This is something most people won't get until they try it, unless maybe they are old-school Lisp hackers.

Now, Spyce isn't quite to the point where it matches ASP.NET feature for feature. But it's close, and getting closer. I checked in an authentication Active Tag earlier today that will be in Spyce 2.1. After that, the only thing I miss from ASP.NET is the (form) validation controls. That will probably also be in 2.1, and then what is Spyce missing? ADO.NET? No, thanks; any feature that has entire books devoted to it has a very suspect cost:benefit ratio. I'd rather use an ORM tool like PyDO. Master pages from ASP.NET 2? Already done. Weird-ass bugs caused by IIS misconfiguration? I think we can leave those out.

Microsoft ahead of Sun in dynamic language support

Microsoft's Chris Anderson writes:

...our singular focus on strongly typed compiled languages has blinded us to the amazing productivity and approachability of dynamic scripting langauges like Python and Ruby. I'm super excited that we are changing this. Hiring Jim Hugunin [to work on IronPython is a great start.

Jython has long been the only Python (or any major dynamic language) implementation on a Big Platform VM, and it's still substantially more usable than IronPython despite months/years of languishing while Samuele Pedroni as the sole "active" project admin wrote little code and checked in less, much to the dismay of people who wanted to work on Jython. (Not that I'm bitter.) Now that Brian Zimmer got a PSF grant to work on Jython, thinks are finally moving again, slowly.

But despite the moral support from Sun managers like Tim Bray, Sun really hasn't done much for dynamic languages on the JVM. Sure, they hosted a meeting last year on the subject, and they support scripting their NetBeans IDE with Jython and Groovy, but that's extremely lukewarm support compared to Microsoft's hiring two developers full-time to work on IronPython.

The party line, I've heard, is that Sun doesn't want to show favortism to Jython over, say, Groovy. Which is a crock; Jython is stable and fairly widely used, as such things go; Groovy may not be quite the unholy mess it was earlier this year but it's clearly got a few years to go before it gets to a Jython-like level of maturity. If Sun were interested, the obvious thing is to support Jython now and Groovy, JRuby, etc., when there is sufficient community interest.

Which is why if my current employer drops Python in favor of JSP, as seems likely, I'll probably take a .NET gig over a Java one if I can't find more directly python-related employment.

Monday, May 16, 2005

Spyce 2.0 final

Spyce 2.0 is available here.

"You've taken spyce off my 'disgusting template engines' list. This is how I'd want to see apps structured, exactly."
    -- Tim Lesher
"I feel easily five times as productive in Spyce as I do in JSP."
    -- Conan Albrecht

Spyce is a python web application server, combining the features of popular frameworks such as JSP and ASP.NET with Pythonic elegance. Spyce may be deployed as a standalone server (or proxied behind Apache), or under mod_python, FastCGI, or CGI. Documentation and demos are here.

Highlights of Spyce 2.0 include:

Thursday, May 12, 2005

Trial periods for software developers

Tim Lesher has an interesting post about applying meritocratic principles to hiring software developers. He suggestion is to hire developers as contractors for a trial period before taking them on full-time.

If you as a hiring manager aren't sure about someone, either on a technical level or just fit with your team, this makes sense. I didn't have precisely this experience when I started as an instructor at Northface, but I did start at a lower salary with an explicit "if you're still here in 3 months, here's what your salary will rise to." (This was primarily because they wanted someone to teach ASP.NET, with which I had no experience at the time.) I thought this was a pretty fair approach, and much better than a rigid "if you don't have the right keywords on your resume, don't bother no matter how good you are."

But companies won't bother giving the "maybe" candidates a trial period if they think they can find a "yes" candidate in a reasonable time. Not out of malice, and not even out of stupidity: even with a good candidate, they know that net productivity will decrease temporarily while one or more of the existing team answer the new person's questions and otherwise help him get up to speed; the bigger the project, the longer this lasts. With a "maybe" candidate, the odds that the eventual increase will make up for that only get worse.

Companies with smaller projects can better afford the risk, but they will still prefer to hire someone they are sure will be an asset than take chances.

Later at Northface I did the technical interviews for instructor candidates. The majority really were "yes" or "no."

That experience, incidently, is one reason I view with deep skepticism the claims by many of the slashdot crowd that there's plenty of hotshot American programmers looking for jobs, so we don't need no steekeen unwashed H1-B visa holders. Many if not most of the ones we didn't call back were the sort who, for instance, claimed years of MySQL, Oracle, and Sybase experience but couldn't tell me about any differences in their SQL dialects. Or the Java programmers who got wrong something like

class Dog {
    public String name;

static void foo(Dog d) {
    d = new Dog();
    d.name = "Rex";


Dog d = new Dog();
d.name = "Prince";

// What is d's name?

So while contract trial periods can be useful, I think there are solid reasons why you don't see companies doing that more often. If you really want to move into the hot new *cough* Python field, work on an open-source project. Start a blog. Bring a USB drive with code you've written to the interview. Floss. Don't be a "maybe."

Wednesday, May 11, 2005

Materialized views in PostgreSQL

One thing I've wanted to write about for a while is materialized views in PostgreSQL. Materialized views are basically precomputed views; they're very very useful if you have an expensive query against data that doesn't change much. This is one of the tricks I use to keep the db overhead on Carnage Blender reasonable.

Oracle and DB2 are the only RDBMS products that can auto-materialize views for you, but you can rig them yourself in PostgreSQL or anything that gives you a powerful enough trigger + procedural language. (And if performance is crucial, you'll end up hand-optimizing them in Oracle/DB2 as well. At least, back when I used Oracle in the 8.1 days.)

But while looking for examples of a certain PL/PGSQL feature this morning, I found Jonathan Gardner's materialized views page (link may be down; see the archive.org copy) which covers the subject so well that now I don't have anything left to add. Nicely done!

Incidently, this is just one more reason real procedural languages in the database are critical for most substantial projects. Implementing materialized views in your application logic would be worse than a joke.

Monday, May 09, 2005

Emacs support for Spyce

Committed spyce.el in svn contrib/. (For those of you not bound to it by 10+ years of habit, el stands for Emacs Lisp.) I didn't write a "spyce mode" per se; I just used the mmm-mode module to allow Emacs to recognize the python snippets inside html. mmm-mode is one of the most complex modules I've had to work with, and while it gets the job done, to me it seems like emacs is showing its age. Maybe one of the DrPython guys will write an Emacs keybinding package so I don't feel too lost.

This is about as simple as you get with mmm-mode. You can get a lot more complicated.

(require 'mmm-auto)
(require 'mmm-sample)
(setq mmm-global-mode 'maybe)
(setq auto-mode-alist (cons '("\\.spy$" . html-mode) auto-mode-alist))
(setq auto-mode-alist (cons '("\\.spi$" . html-mode) auto-mode-alist))

    :submode python-mode
    :front "<%"
    :back "%>")
    :submode python-mode
    :front "\\[\\["
    :back "\\]\\]")
(mmm-add-mode-ext-class nil "\\.spi$" 'spyce1)
(mmm-add-mode-ext-class nil "\\.spy$" 'spyce1)
(mmm-add-mode-ext-class nil "\\.spi$" 'spyce2)
(mmm-add-mode-ext-class nil "\\.spy$" 'spyce2)

Thursday, May 05, 2005

Looks like spyce will have to find a new home

SF.net just sent out an email to project admins saying, among other things, that project web space will soon be mounted read-only. Bleh. That means I just wasted a LOT of time tweaking the Spyce makefile to auto-deploy to sf.net for no reason, because both of the new demos want to be able to write to disk. (One because it uses durus, and the other because since SF runs in CGI mode, the pool module pickles and unpickles itself to disk for each request. Which sucks rocks for performance, of course, but if you cared about that you wouldn't be using CGI, now would you?)

Of course spyce.org is already taken by someone who isn't using it...

I guess the bright side is now I can go ahead and enable comments on the Spyce documentation once it moves, if I have the time to wrestle with the TOC (table-of-contents) module to get it to spit out appropriate .spy files instead of html. (Making it into a wiki is another attractive option, but the nice thing about the TOC module is you can easily generate a single-page version for printing.)

(Incidently, with SF apparently modernizing many of the other aspects of their operation, when are they going to offer a better database than MySQL?)

"a new web framework named spyce"

Dion Almaer writes in a sort of footnote to his Python has a leg up in the dynamic language race post that

[T]here is also word that a new web framework named spyce is going to try to do what Rails has done for Ruby.

I think there are definitely some points of commonality if you take a big picture view; primarily, both are about leveraging the capabilities of dynamic languages to provide an environment vastly more productive than is possible with traditional staticly-typed-languages (Java, C#).

How we go about that, though, is quite different. Spyce isn't trying to be a Rails clone a la Subway; it's its own beast. Spyce is more page-centric, like ASP.NET or OpenACS. Like all modern frameworks, Spyce encourages separation of code and markup, but it's not religious about forcing one man's vision of MVC down your throat.

And while strictly speaking Dion is wrong to call Spyce "new," Spyce 2.0 has a much, much more modern feel to it than 1.x. If you evaluated Spyce a couple years ago, have another look.

Wednesday, May 04, 2005

Spyce 2.0 beta released

Some 217 commits into development, Spyce 2.0 is finally available for download. The main Spyce site has been updated with the new docs, examples, and demos.

Full changelog is here; highlights include

  new-style active tags 
    - docs
  OpenACS-like (Tiles-ish, for you JSP people) parent/child templating system
    - roughly the same speed as include.spyce, so using one parent template
      has about 1/2 the overhead as the old standard 
    - docs
  Active Handlers
    reusable components without the leaky abstraction of ASP.NET et al.
    - docs

The only major change since the prerelease was announced on this blog is that the class chunk token was changed from [[\\ to [[!. At least that's the only one I remember after spending the last 5 days wrestling with sourceforge's cgi-bin.