PyMeld and PyMeldLite (was Re: Separation of content and code for web)

Peter Hansen peter at
Tue Dec 2 17:35:45 CET 2003

Richie Hindle wrote:
> Note that the Sleepycat license means "closed-source redistribution for a
> fee only" - any redistribution with full source is free, and commercial
> *use* on your own server machines is free (rather annoyingly for someone
> who wants to make money from server-based software but remain
> GPL-compatible and generally Open-Source-friendly).  (If this sparks a
> licensing rant, *please* start a new thread, whoever does so!)

I don't think this is a rant, but I changed the subject anyway. :-)

The reason that license wouldn't be suitable for us is that we build
embedded web server interfaces into some of our products, allowing them
to be monitored and configured remotely via the web.  Very nice way to
go, but of course it would by definition require us to be able to 
redistribute the code.  It's not just going to be in our own servers,
but in effect installed on servers that we sell to others.

> If it's a choice between relicensing under the BSD license or being
> superseded by a better implementation released by you under a BSD license,
> I'd be quite happy to relicense PyMeld under a BSD license.  I don't have
> the time to improve it myself, and I don't believe it's a viable
> commercial product for a lot of people because of its limited performance,
> so I'd rather it survived and grew under a completely free license than
> died.  Improving the performance is not hard, but I don't have the time.
> You might want to also look at PyMeldLite, which is currently available as
> part of the SpamBayes project.  That's Python-licenced, and has exactly
> the same API and capabilities as PyMeld.  The reason it's 'Lite' is that
> it only works with perfectly valid XHTML, whereas PyMeld will work with
> any old real-world HTML you care to throw at it (pretty much).  

Very interesting... we built ours around a sort of ElementTree-lite that
we whipped up -- which is based on the expat parser, and which therefore 
also handles only valid X[HT]ML as well.

I'll take a more detailed look at PyMeld[Lite] and see what we can do 
with it, either way.  Looking again at the examples, I think I might end
up concluding I like our API better, although I know yours could appeal
more widely.  The reason I say that is that you've done things like make
items with "id" attributes available as named attributes of the PyMeld
object, whereas we concluded that since an id could contain things that
weren't legal in Python names, we should stick with a dictionary approach
instead.  We could have chosen to allow that merely as a fallback, but
then we'd have two obvious ways to do something and we are trying to be
more Pythonic.

Thanks again, Richie!


More information about the Python-list mailing list