I like the deferred model (a-la Twisted), and it's there. I like the signal-slot mechanism (a-la Qt or Pydispatcher), and it's there. I like functional programming (a-la map, and friends) and it's there. Even the programmattic creation of html is pretty sweet (nevow's stan inspired). Basically the code looks just about how I would expect the code to look, short, concise, but readable and easily maintained.
After half an hour with the library I was writing most of my code without reference to the documentation. About the only thing that really tripped me up was that the signal-based code for onload needs to be bound to the *window* in order to work... rookie mistake I suppose. That small-enough-to-fit-in-your-mind and regular-enough-to-predict-what-will-be pattern is IMO extremely Pythonic.
One last thought. Am I the only one who finds that kid/genshi is best exploited by passing model objects directly to the view? I know, I know, the controller should resolve everything to low-level values before invoking the view... but it's *so* nice to be able to use SQLAlchemy/Elixir bindings to traverse the objects and use common function definitions to provide a consistent view of the objects wherever they show up... being able to say "conference.owner.company.name" to display the value is just so convenient... even if it does wind up embedding code in the view.
Pingbacks are closed.