Entries classified under python

Kid 0.6 is available.

This is a feature release with some pretty important enhancements including Template Inheritence, Match Templates (kind of like XSLT's), cElementTree support, and a refined Python API. Quite a bit of time was spent on the documentation as well.

The Release Notes have more information on everything that has changed.

Kid is an XML based template language for Python that merges the best of Zope's TAL, PHP, and XSLT into a single coherent package. It was created to provide a simple method of generating dynamic, well-formed XML documents using familiar concepts from popular text templating languages.

Download

http://lesscode.org/dist/kid/

Release Notes

http://lesscode.org/doc/kid/0.6/notes.html

Project Information

http://lesscode.org/projects/kid/

These numbers look pretty bad... or good, depending on where you stand, I guess. I find it hard to believe that Rails is that much slower than Quixote/Durus for a truly similar task but hey I'm on the right side of this one so I won't complain too loudly.

Mike, you've given some info about the tests but it would be really helpful if you provided everything needed to recreate them. Specifically, the versions of Rails/Instiki/Quixote/MoinMoin and the specific URI stems you were pointing to with ab. Otherwise stuff like this can be taken the wrong way and turn into a big Python-vs-Ruby flame-fest. If your numbers are correct, I can't see the test setup making a whole lot of difference but still...

There are lies, damn lies, and statistics, unless you provide absolutely everything needed to recreate the statistics, in which case there are only lies and damn lies. We can reduce this a little further by removing the speculative concept of damnation, leaving us with just lies. This is probably the best we can do without killing everyone, which I'm not sure we can accomplish in any predictable time-frame.

LATER: Mike takes a closer look at his tests, revealing some issues with the comparison method.

Anyway...

I also wanted to comment on some of the RDBMS vs. Durus/ZODB stuff as I've been down this road myself and have been meaning to write about it a bit.

Mike compares relational persistence and object persistence:

Rails has a SQL object relational mapper; Quixote imposes no such thing but doesn’t get in your way of using SQLObject, ORM, Cucumber, any other o-r mapper, or no o-r mapper at all. I’ve done all of the above, but am slowly retiring all my SQL based code (where sensible) in favor of Durus, a ZODB inspired object database. Quixote sister project “Durus” provides an easy to use object database which is far more productive than force fitting objects to SQL. Durus certainly not limited to writing web apps.

Object databases like Durus/ZODB and relational databases are apples and oranges (or possibly oranges and mangos). I've recently been down the let's put everything in ZODB path and it comes with some problems:

• ZODB/Durus using FileStorage can only be accessed by a single-process.

• ZODB/ZEO or Durus/ClientStorage can be accessed with multiple processes over a network much like most relational databases but there is no concept of "multiple databases". If you want multiple databases, you need multiple ZEO servers running.

  LATER: Richard Jones corrects me on this and also the packing thing below.

• Durus has issues with multi-threaded access.

• There's not a lot of cheap hosting options that have ZODB/ZEO running out of the box or that will let you run any number of long-life processes.

• ZODB maintenance (packing) is a pain in the ass, IMO.

• Indexing is hard. The BTree classes get the job done but handling multiple indexes on objects can be tedious as you have to keep multiple BTrees in sync manually. (No I'm not talking about the full text index catalog crap. I need fast lookups on specific attribute values).

• Only Python code can access the database. I shrugged this off at first but found that it's actually really² nice to have data in some kind of language-independent storage.

There are a whole range of situations for which these issues aren't really issues at all and relational persistence has its own set of issues. But in my experience, making the decision between ZODB and relational has been less about what's better for the code and more about what's better for the data. That being said, I use ZODB quite a bit where I used to throw up hacks around pickles and shelves and also when I know I will have complete control over the application environment and don't have to play nice with others.

I've been enjoying David Heinemeier's (Ruby on Rails / 37signals) blog lately. The kid has excellent chin, which seems to be a requirement for dynamic language advocates mingling with the static language community. In his latest, Serving the koolaid with the facts, he takes on some of the criticism coming out of the Java weblogs that targets various aspects of Rails that go against conventional static language thinking.

It's really easy to take a concept that fails in a given environment and put it into the that's always bad part of your brain. Later, you see the same concept in a different environment and the that's always bad fiber starts blipping like crazy and your mouth starts saying things like, That's always bad.

There seems to be a trend emerging in conversation between the dynamic and static language camps that I believe is based in this flaw in the human mind. There are so many aspects of dynamic language programming that really just don't work in a static language environment and the opposite is also true; one is an ocean and the other dry land. Unfortunately, this isn't immediately apparent and those with strong backgrounds in one environment have a tendency to misjudge the viability of approaches in another.

Fish? That will never work.

I think the key to overcoming this problem is just to keep on talking. Over time it will become apparent that you can't measure dynamic language approaches under the static language microscope and then maybe we can just get on with things and start figuring out where the two environments can work together. It is perhaps not an accident that some of the most beautiful places in nature are the coasts where two strange environments meet.

Dan Gillmor points to an excellent example of distributed journalism in action over at Daily Kos. I was completely blown away by what I saw when I got there. I'm still trying to soak in all the background around the Plame Leak / Jeff Gannon thing but, to be honest, the specifics of this event are not as important to me as the general phenomenon occurring there. This seems an obvious glimpse into a future where involvement by the general population in issues of import to the general population is increased substantially. Herewith some rant and analysis of our present toolset and humble suggestion for improvement...

Kid 0.5 is available and I think I finally like it enough to start dumping out some example templates and API usage...

This is the second article following up Phillip J. Eby's Python Is Not Java. In the first article, The Static Method Thing, we took a look at how Java static methods differ from Python class/static methods. This time we're going to dive deep into the evils of getters and setters.

I had a very small number of complaints related to basing Kid on ElementTree. This came in two forms:

1. SAX and DOM are “standard” and while ElementTree is a drastically improved system for processing XML in Python, it doesn't matter because everyone already knows SAX/DOM.

2. “libxml2 is teh rawk!”

First, if Python's W3C DOM standard based xml.dom package were a movie, it would be called Elf, staring xml.dom. It's the episode of Little House on the Prairie where Alien asks Michael Landon for permission to marry his daughter. It does not belong here!

Next, in terms of pythonicness, libxml2 is almost worse than xml.dom but you at least get something for it: they don't even have a word to describe this level of “fast” and it comes along with XPath, RelaxNG, XSD, XML-Base, XInclude, and XSLT. My issue with libxml2 is just that it's a bad dependency for a project like Kid that wants to be able to run on cheap web space with bare-bones Python support. There are a lot of hosting providers that aren't going to have libxml2 or the option of compiling from source.

I went with ElementTree because it's simple, pythonic, and fast enough. I also had a feeling we'd be seeing more development around ElementTree, which brings us nicely to why I'm posting.

I completely forgot to mention what is quite possibly the most important event to date in Kid history: the first real application to incorporate Kid templating is Ross Burton's sexy Tate (I said, “sexy Tate,” not “sexy Taint!”). It's an elegant, RDF / XHTML photo gallery that I'm dying to get my hands on. If you're into nice semantic usage of (X)HTML, make sure to peep the page source and check out the correct usage of <ul>’s and whatnot.

Ross has reported a few issues and even mentioned plans for packaging Kid for Debian. He's the proprietor of the excellent Sound Juicer CD ripper for GNOME 2, Debian contributor, and takes some kick-ass photos to boot.

Phillip J. Eby has a recent weblog entry, Python is not Java, wherein he points out a few aspects of Python that are notably different from Java but that are similar enough that Java coders working in Python mistake them for their Java counterparts.

He touches on a few of the characteristics that led me to make Python my general purpose language of choice, a title that had belonged to Java as recently as a year ago. I thought it might be useful to explain these characteristics without assuming the reader has a whole lot of Python experience but that they do have significant Java experience. This would have helped me immensely in determining whether Python was right for me much sooner and I hope it can be of use to someone else.

I'm planning on covering each of the items Phillip points out in his article over the next month and if that works out, I may extend the series to a few other things that may be useful.

This is not a Python is better than Java thing. Instead of bashing aspects of Java's language and library that are obviously valued by the Java community, or insulting the intelligence of Java coders, or using any number of other techniques you might find in Every Language War Ever, Phillip is simply asking Java programmers who may be dabbling in Python to take a closer look at some of the features that make Python unique and attractive instead of attempting to force-fit concepts from Java. If you base your expectations of Python on Java concepts, you are likely going to have a bad experience with Python.

Continue on for the first part of the series, which talks about some of the differences between Python class methods / class variables and Java static methods / static variables.

I was searching for a specific piece of Dive into Python when I ran into this classic from diveintomark.org:

Tom: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Tom: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Tom: "But the world doesn't work that way."
Mark: "Mine does."

I had to pour out a little liquor for my homies.