The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Weblogs Forum
Django vs. Cheetah: 1-0

86 replies on 6 pages. Most recent reply: Jan 27, 2008 10:34 PM by Johnny Stovall

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 86 replies on 6 pages [ « | 1 ... 3 4 5 6 ]
Mike Orr

Posts: 2
Nickname: sluggo
Registered: Feb, 2006

Re: Django vs. Cheetah: 1-0 Posted: Feb 5, 2006 5:10 AM
Reply to this message Reply
Advertisement
Hi everybody, I just saw this discussion now. Andrew Kuchling mentioned my suggestion for doing smart escaping in Cheetah, where most $placeholders are HTML-escaped but you can mark certain ones as preformatted using Quixote's htmltext() wrapper. URL: http://linuxgazette.net/117/orr.html

This broke in Cheetah 1.0 RC 2 because Cheetah now uses ''.join(list_) rather than StringIO to concatenate the output. Join requires a list of bona fide strings, which htmltext() is not. I have two production sites that are stuck at Cheetah 1.0 RC 1 because of this. I want to try this using QPY's u8() instead, which is a unicode subclass. I've hesitated mainly because of the 33 production templates I'd need to test thoroughly. I'm not sure what will happen if the rest of the template is not Unicode, whether it'll blow up or force it everything to Unicode, and whether that would have any negative ramifications in a Quixote site.

Cheetah has "dumb escaping": the WebSafe filter will escape all $placeholders, but you have to explicitly turn it on and off. I've suggested some sort of optional smart escaping for Cheetah 2.0. (2.0 is in RC stage now awaiting a documentation update.)

Guido suggested a standard way in the Python library to mark a string as preformatted so it isn't escaped further by any template system. YES! We are all using ad hoc ways to get around this. It doesn't have to be subclasses of str/unicode. A simple boolean attribute: ''.preformatted, default False, would do it. The only reason we're using subclasses is because you can't add an extra attribute to str/unicode: they apparently use __slots__.

Regarding $placeholder for escaped values and #include for preformatted values, that's not how Cheetah's #include works or was intended. #include is for inserting an external file as if it were part of the template. "#include source=$var" is used to "eval" a string containing Cheetah markup. "#include raw source=$var" would almost insert the string literally but I think the filter would still escape it. In any case, #def's almost always return preformatted HTML, and it would be a pain to use that syntax for every method call.

Regarding Cheetah's verbose syntax for expressions, Cheetah 2.0 supports ${a + 2}, borrowed from Kid. The new docs will not recommend $ inside expressions except where necessary (for searchList lookup); this should clear up the confusion regarding $.

--Mike

Mike Orr

Posts: 2
Nickname: sluggo
Registered: Feb, 2006

Re: Django vs. Cheetah: 1-0 Posted: Feb 5, 2006 5:21 AM
Reply to this message Reply
I mean, ${a + 2} is a placeholder calculated from an expression. Expressions inside directives remain unchanged:

Old recommendation
#for $i in $range($a + 2)

New recommendation if 'a' is local variable
#for i in range(a + 2)

New recommendation if 'a' is in the searchList
#for i in range($a + 2)

"Local variable" means it came from #set or #import or is a Python builtin, etc.

Although I will probably continue to write "#for $i in range(a + 2)" because old habits die hard.

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Django vs. Cheetah: 1-0 Posted: Feb 5, 2006 9:51 AM
Reply to this message Reply
> New recommendation if 'a' is local variable
> #for i in range(a + 2)
>
> New recommendation if 'a' is in the searchList
> #for i in range($a + 2)
>
> "Local variable" means it came from #set or #import or is
> a Python builtin, etc.

I'm not sure that this is any less confusing.

Jeff Hinrichs

Posts: 2
Nickname: dundeemt
Registered: Feb, 2006

Re: Django vs. Cheetah: 1-0 Posted: Feb 5, 2006 9:05 PM
Reply to this message Reply
Have you developed realistic web applications yourself?

Yes, actually I have. Some rather large catalog sites (10,000+ skus / multi-segment customer bases), been doing this for 10 years and have worked the one-developer hero to the multi-person/discipline team. (tools used over the years: shell scripts+raw html+cgi/ iis+asp/ apache+php / iis+python / apache+python) I see you argument about controller versus ui logic. And I understand how people can disagree on it. However, I would argue that you already know how many responses/items there are after you query your persistent storage for the items. At this point, I contend, you are in a better position to handle the returned data to the UI. You are splitting logic for a single thing to two different places. (A similiar argument is made in db vs app logic debate in forums elsewhere<g>)

By keeping as much logic in a single place:
1) you write code that is easier to read and thus easier to test. (Granted, I have been using selenium for most of my testing for more than a year now -- I helped start out cPAMIE but selenium is the way to go for web testing now.)
2) You are most likely already wrapping that persistent storage access with a mechansim to test the sanity of the return and error trapping anyway, so adding the test for number of returned records is being done there already, extending it is trivial.
3) When creating large scale web apps, consistency is key. So if a developer decides to split this type of logic into the UI then it should be easily definable when logic should be in the UI as opposed to the controller.

How did we do it without loops or conditionals in the template?
By simple substitution and returning/substituting standardized html blocks (i.e. a complete <ol>,<ul>,<table>, etc*) to be used for substitutions.

Also, by allowing templates to include other templates. At the base template level, we knew how the site was to be designed i.e. a standard width or completely flowing. The types of tags (meta/header) that we were going to be using. Some pages were product and used the product.body.template to override the body section of the layout, same for nav and other sections of the pages.

The place where smart template languages get evil, is when you are trying to modify the page based on whether the customer was "logged in", and/or a specific customer class. This was much easier to design, code, debug in the controller than in the UI. As another example, imagine implementing logic to show shipping options based on product attributes (weight/size/hazmat), customer class (i.e. dealer/individual/corporate) and destination (domestic/intl)

That is not something I would cherish being in the UI logic and is much more cleanly handled by keeping it tucked away in the controller.


-Hypothetical-------------
* a simple html helper class that builds these objects in an OO fashion is trivial to write and makes the html block creation part drop dead simple.
for example
...
def getRelatedItems():
  htmlOrderedList = htmlhelper.OrderedList(cssClass='cssRelated')
  ...
  somecode here -- try/except around the persistent
  retrieval mechansim
  ...
  if returnedRecs:
    for rec in returnedRecs:
      htmlOrderedList.addItem(rec['foo'])
  else:
    htmlOrderedList.addItem('No Related Items')

  return htmlOrderedList.construct()

....
Template.add('relatedItems',getRelatedItems() )
Template.publish()

-----------template---------------------
...
{{ relatedItems }}
...


If you take this same hypothetical and push the logic out to the template as you describe -- which one would you rather maintain??

In conclusion, the logic constructs templating languages give are too limited and crude to be useful for non-trivial logic implementations. So if there is going to be some co-mingling of logic -- haven't found a clean workable solution for total seperation yet -- I favor full flavored python controller over a not-python or kind of like python templating langauge.

-Jeff Hinrichs

Ron Phillips

Posts: 2
Nickname: paron
Registered: Feb, 2006

Re: Django vs. Cheetah: 1-0 Posted: Feb 6, 2006 10:33 AM
Reply to this message Reply
> <p>I guess we're closer than I thought to the
> mix-and-match approach that I requested in my previous
> blog. Cheetah is <em>just</em> a templating engine, and
> several web frameworks use or recommend it, e.g. web.py
> and Subway. (Is Subway dead? The website is
> super-incomplete and it still downloads an old Cheetah
> version.)

Last I heard, there was talk between Subway and TurboGears developers about combining the projects.

Ron

Shannon -jj Behrens

Posts: 12
Nickname: jjinux
Registered: Aug, 2005

Re: Django vs. Cheetah: 1-0 Posted: Feb 9, 2006 11:20 AM
Reply to this message Reply
"As simple as possible, but no simpler."

I have a lot of respect for what the Django guys have done. I actually really like a lot of Django. However, having tried it, I find the templating engine to be elegant, but too simple. What frustrates me most is the lack of functions. In my first programming class, I learned how to use functions for code reuse. DRY applies even to HTML. At my company, even the "template authors" know how to create a function to avoid code duplication. Nor is the "include" or "block" statement a suitable replacement--functions have parameters. Different arguments lead to different results. This is necessary functionality. Also, functions should support recursion. I learned in my second programming class how to think recursively, and every once in a while it really comes in handy (for instance, when you're writing a bulletin board application with a hierarchy of messages).

When I was using Django templates, I really felt like my hands were tied. I don't think lack of functions improves security. I don't think custom tags are always a suitable replacement--I'm talking about simple HTML reuse. Please forgive my boldness, but I don't think I should have to live without functions just because a template writer working at some other company doesn't understand them.

Next, I think I'll try out using Django with Cheetah. So far, Cheetah has always met my needs exceedingly well. Hopefully, I can get it to fit in smoothly, maintaining Django's overall elegant feel.

Andrea Arcangeli

Posts: 2
Nickname: arcangeli
Registered: Feb, 2006

Re: Django vs. Cheetah: 1-0 Posted: Feb 25, 2006 7:43 AM
Reply to this message Reply
Hello everyone,

Just a few comments on this part (disclaimer I didn't try Django but I know Cheetah pretty well):

------------------- quote start -----------
Cheetah, OTOH, compiles each template to a Python class! This is much slower, and in my experience brittle -- on my first attempt I introduced a syntax error in the template that caused a Python syntax error in the resulting Python class, which was hard to debug. It also seems overkill, and I worry that it might cause security problems -- given that the compiler isn't too smart (see above) I could see a malicious template author "breaking out" of the templating languages and invoking unauthorized Python code. Now, I wouldn't let people I don't trust edit templates on my website anyway, but it appears to be a common pattern that certain people are allowed to edit templates but not code. Cheetah blurs the distinction a little too much for my comfort.
------------------- quote end -----------

Ok the first time the compilation happens it may well be slower, but then the resulting class bytecode is cached and it's optimally written to execute just the needed steps to output the html (or whatever else target).

For example if you disable fitlers, the filter calls will go away from the compiled bytecode, and it won't cause anymore overhead.

I would like eventually see Cheetah speaking in terms of twisted deferreds for example, and that will be only a "compilation" cost. Clearly not everyone will ever understand async code and the deferreds mechanism, so it would be bad if the deferred would cause overhead to people not using them (they already pay an hefty price with overkill amount of stacks and therad related overhead when a thin data structure passed to epoll could achieve the same). So the compilation would generate a different python class (with a different html rendering method) depending if you enable the deferred-speak or not. This is the direction I want to see CPUShare-Twisted (http://www.cpushare.com/twisted) going.

So to me the compilation cost seems an huge speed benefit, the opposite of what you described above (especially when working with pre-compiled templates, though I don't use them).

I think other languages like Nevow tries to do some parse-caching, but
regardless of the caching it does to avoid reparsing xml every time, I
measured nevow is close to 10 times slower in the rendering than Cheetah (sure a lot slower than 5 times, measured on ppc64 and x86-64 with python2.4),
and it's a lot more compicated and less flexible. I can't speak for Django performance since I never tried it,
but I'd be surprised if Django can be any faster than Cheetah (starting from the second rendering invocation after the compiled bytecode is cached by the class.hash), did you run some benchmark comarping Django to Cheetah?

About the security point it will definitely cause security problems if you allow untrusted people to edit the templates.
This is because you can import any python module and execute any python
code from the template. You can't import a template if you don't trust
it. But is this any different from php where code and html are mixed in
the first place?

I'm using Cheetah successfully so far for KLive and CPUShare and I'm really happy about the ~ten fold performance boost in html rendering I got.

I know if using python performance should not be very relevant, but it really is, performance is always relevant. One of the reasons to use python (or ruby or other similar languages) instead of C is to decrease the time-to-market, but if with the same developer-time you can render html 10 times faster and divide the number of servers you need by 10, that's very significant.

On the debugging side I never had significant problems with Cheetah, the only screwed thing I get is the fact Cheetah shows the line of the exception in the compiled class, but I never get to see the source of the compiled class because I don't use precompiled templates. But the exception also provides more info and not only the exception line, so I never had problems to fix things. I also like the strict behavior where if a parameter is missing an exception is raised.

On the debugging front the only thing that I really miss and that everyone would get benefit from, is not related to Cheetah but it's a very python thing. That is the nevow exception handler in html inside the browser you can see it here:

http://divmod.org/trac/browser/trunk/Nevow/nevow/failure.py

See the formatFailure class. I've seen posts of people moving from nevow to CheeryPy also feeling the lack of this piece of code. That is a function that extracts all local variables and shows them along the exception in all frames. That really should be generalized, de-stanned, and made generic somehow, so that it works for normal exceptions too and not only for twisted failure objects (and with html and text targets, I work with test normally since showing exceptions in the browser is unsafe).

I'm probably going eventually to implement something similar in my twisted-cpushare project as a standard API eventually, and I'll use it to send me all the relevant debugging info by email and sms when an exception triggers (currently I only get the exception, without local variables and context).

One last bit: I also like the fact how Cheetah is a standalone lib and self contained.

Thanks everyone for these open source products.

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Django vs. Cheetah: 1-0 Posted: Feb 25, 2006 9:33 AM
Reply to this message Reply
> On the debugging front the only thing that I really miss
> and that everyone would get benefit from, is not related
> to Cheetah but it's a very python thing. That is the nevow
> exception handler in html inside the browser you can see
> it here:
>
> http://divmod.org/trac/browser/trunk/Nevow/nevow/failure.py
>
>
> See the formatFailure class. I've seen posts of people
> moving from nevow to CheeryPy also feeling the lack of
> this piece of code. That is a function that extracts all
> local variables and shows them along the exception in all
> frames. That really should be generalized, de-stanned, and
> made generic somehow, so that it works for normal
> l exceptions too and not only for twisted failure objects
> (and with html and text targets, I work with test normally
> since showing exceptions in the browser is unsafe).

Isn't this similar to the cgitb.py module in the standard library?

Andrea Arcangeli

Posts: 2
Nickname: arcangeli
Registered: Feb, 2006

Re: Django vs. Cheetah: 1-0 Posted: Feb 25, 2006 10:36 AM
Reply to this message Reply
Yes it looks similar to cgitb.py (I like it already has a text output target), I'll look into it and see if I can use it instead of the nevow code for it. Thanks.

bob the builder

Posts: 2
Nickname: sbot
Registered: Dec, 2006

Re: Django vs. Cheetah: 1-0 Posted: Dec 6, 2006 4:42 PM
Reply to this message Reply
wat the hell r u on u smack head...

bob the builder

Posts: 2
Nickname: sbot
Registered: Dec, 2006

Re: Django vs. Cheetah: 1-0 Posted: Dec 6, 2006 4:43 PM
Reply to this message Reply
> <p>Encouraged by Fredrik Lundh, I took a look at Django
> templating, separate from the rest of Django. This works
> fine, except there's a mysterious environment variable
> DJANGO_SETTINGS_MODULE that is somehow <em>required</em>.
> That may be fine for framework users, but it's a bit
> t harsh if all you want to do is use the templating
> library. Setting it to empty didn't help. I ended up
> uing this hack:</p>
> <pre class="literal-block">
> import os
> os.environ["DJANGO_SETTINGS_MODULE"] =
> "__main__"
>
> from django.core.template import Template
> </pre>
> <p>With that out of the way, I managed to run this
> program:</p>
> <pre class="literal-block">
> t = Template("<h1>Hello
> {{name}}</h1>")
> print t.render({"name": "Phillip"})
> print t.render({"name": "Adrian"})
> </pre>
> <p>This is nice! The output of course is:</p>
> <pre class="literal-block">
> <h1>Hello Phillip</h1>
> <h1>Hello Adrian</h1>
> </pre>
> <p>Unfortunately I had trouble installing Django for the
> Python 2.5 alpha that I've got installed; it uses the
> fancy new ez_install stuff, which is great when it works,
> but there's no Python 2.5 download of setuptools on PyPI
> yet, so it doesn't.</p>
> <p>I tried the same exercise using Cheetah. Not too
> different:</p>
> <pre class="literal-block">
> from Cheetah.Template import Template
> names = {"name": "Tavis"}
> t = Template("<h1>Hello $name</h1>",
> searchList=[names])
> print t
> names["name"] = "Ian"
> print t
> </pre>
> <p>with the following output:</p>
> <pre class="literal-block">
> <h1>Hello Tavis</h1>
> <h1>Hello Ian</h1>
> </pre>
> <p>(Ironically, Cheetah also failed under Python 2.5 --
> Python 2.5 inadvertently (I believe) changes the syntax
> that's allowed before "from __future__ import
> ..." to disallow assignment to __author__ and
> __version__. That was easier to fix though -- commenting
> out the "from __future__ ..." line was
> sufficient.)</p>
> <div class="section" id="side-by-side-comparison">
> <h1><a name="side-by-side-comparison">Side-by-side
> Comparison</a></h1>
> <p>(<strong>BEWARE!</strong> I haven't used either system
> to build a real website yet. I'm just looking at the API
> and templating language designs.)</p>
> <p>Django definitely feels more "modern" than
> Cheetah. The templating languages are fairly similar,
> with Django writing {{foo.bar}} where Cheetah writes
> $foo.bar or ${foo.bar} for variable interpolation (==
> substitution). The biggest difference is that Cheetah
> allows pretty much arbitrary Python call syntax, e.g.
> ${foo.bar('hello', $name, 42+42)}. Yes, you have to
> prefix variable references in the argument list with
> another $, and there are confusing rules about when the $
> is optional. Django only allows names separated by dots,
> using the old Zope trick of trying x['y'], x.y and x.y()
> when the input is {{x.y}}. When y looks like a number,
> it'll even try a sequence index, e.g. {{x.4}} means
> x[4].</p>
> <p>(Aside: something similar is also found in web.py, but
> there it bothers me, because it's invoked from
> normal-looking Python code. E.g. foo["x"] and
> foo.x are equivalent, when foo is a "Storage"
> object. But this leaves me wondering, what does foo.keys
> mean? The keys method or the value stored under
> "keys"? Zope 2 was similarly confusing with
> implicit acquisition.)</p>
> <p>A big difference: if Django doesn't find a name, it
> inserts nothing; but Cheetah raises an exception. ISTM
> that Django is more user-friendly here, even if its
> approach could be considered error-prone (typos are easily
> missed since they simply suppress a small bit of output).
> In my experience, missing variables are very common in
> n substitution data, and Cheetah requires you to provide
> explicit default values in this case.</p>
> <p>Both templating languages also have a
> "statement" syntax to complement their
> "expression" interpolating syntax. In Django,
> this is written as {% keyword %} while in Cheetah you use
> #keyword. Here I initially found Cheetah a bit more
> readable, since it resembles C preprocessor syntax:</p>
> <pre class="literal-block">
> #if $name
> <h1>Hello $name</h1>
> #else
> <h1.Hello there</h1>
> #end if
> </pre>
> <p>This is written in Django as:</p>
> <pre class="literal-block">
> {%if name%}
> <h1>Hello {{name}}</h1>
> {%else%}
> <h1>Hello There</h1>
> {%endif%}
> </pre>
> <p>which is harder on the eyes and prints more unnecessary
> whitespace.</p>
> <p>But then I stumbled upon Cheeta's inline form, which is
> pretty unreadable due to the symmetric delimiters:</p>
> <pre class="literal-block">
> # if $name # <h1>Hello $name</h1> # else #
> <h1>Hello There</h1> # end if #
> </pre>
> <p>Both languages have tons of other statement-level
> constructs, to do loops, set variables, invoke other
> templates, define blocks that can be used by other
> templates, and more. I haven't explored this much yet,
> but they both seem to cover a similar terrain. I guess
> this is what template authors actually need; or perhaps it
> points to some common ancestor in PHP or JSP?</p>
> <p>If you need your variable interpolations to be
> HTML-escaped (replacing "<" with
> "&lt;" and so on), Cheetah lets you specify
> a default filter in the template (#filter) or when the
> template is created in Python code. In Django you must
> add a pipeline to the interpolation syntax, like this:
> ${foo.bar|escape}. Both support various other filters as
> well, with Django really going wild. I'm somehow
> surprised that HTML-escaping isn't the default -- failing
> to HTML-escape data is the number one vulnerability
> leading to XSS attacks. And in theory you should almost
> never need to provide HTML for interpolation: you're
> supposed to invoke HTML fragments using #include or
> {%include%}. Cheetah at least provides a way to make
> HTML-escaping the default filter throughout a
> template.</p>
> <div class="section" id="python-api">
> <h2><a name="python-api">Python API</a></h2>
> <p>See the examples near the top. I like Django's version
> better: you pass the variable bindings in to the render()
> method. Cheetah lets you specify multiple dictionaries
> with variable bindings, which are searched one after
> another, but it bothers me that these all have to be
> passed to the Template() constructor instead of to the
> render method (which is called __str__() in Cheetah
> :-).</p>
> <p>Django's template compilation is much simpler and IMO
> more elegant than Cheetah: Django parses the template text
> into nodes of various types using a big regular
> expression, and each node has an appropriate render()
> method. Rendering the template in a given context simply
> concatenates the results of rendering each node in that
> context. I imagine this could easily be turned into a
> generator compatible with WSGI.</p>
> <p>Cheetah, OTOH, compiles each template to a Python
> class! This is much slower, and in my experience brittle
> -- on my first attempt I introduced a syntax error in the
> template that caused a Python syntax error in the
> resulting Python class, which was hard to debug. It also
> seems overkill, and I worry that it might cause security
> problems -- given that the compiler isn't too smart (see
> above) I could see a malicious template author
> "breaking out" of the templating languages and
> invoking unauthorized Python code. Now, I wouldn't let
> people I don't trust edit templates on my website anyway,
> but it appears to be a common pattern that certain people
> are allowed to edit templates but not code. Cheetah blurs
> the distinction a little too much for my comfort.</p>
> </div>
> </div>
> <div class="section" id="other-templating-solutions">
> <h1><a name="other-templating-solutions">Other Templating
> Solutions</a></h1>
> <p>I guess we're closer than I thought to the
> mix-and-match approach that I requested in my previous
> blog. Cheetah is <em>just</em> a templating engine, and
> several web frameworks use or recommend it, e.g. web.py
> and Subway. (Is Subway dead? The website is
> super-incomplete and it still downloads an old Cheetah
> version.) Django's templates are almost usable
> independent from the rest of Django; I expect the
> situation will improve once they release the magic-removal
> branch.</p>
> <p>I didn't find too many other templating solutions.
> TurboGears uses Kid which XML-based, like Nevow, TAL etc.
> . IMO these are no contenders because they are
> XML-based. As the Django folks mention, they use
> templates to generate non-HTML text files as well. And
> even if they could be used for this, the verbosity of the
> XML syntax and the inability to do a proper if-then-else
> in XML make template writing using XML a non-starter.</p>
> </div>
> <div class="section" id="final-thought">
> <h1><a name="final-thought">Final Thought</a></h1>
> <p>Django and Cheetah both define a 'Template' class.
> Python's standard library also has a Template class (in
> n string.py), which serves a similar purpose (but with
> only a fraction of the functionality). All these have
> different APIs. But are the differences important? It
> seems pretty arbitrary whether to use <tt
> class="literal"><span
> class="pre">Template("...").render(locals())</spa
> n></tt> (Django), or <tt class="literal"><span
> class="pre">str(Template("...",</span> <span
> class="pre">searchList=[locals()]))`</span> <span
> class="pre">(Cheetah)</span> <span class="pre">or</span>
> <span
> class="pre">``Template("...").substitute(locals()
> )</span></tt> (string.py). Perhaps we could attempt some
> standardization here similar to WSGI?</p>
> </div>

Hello everyone,

Just a few comments on this part (disclaimer I didn't try Django but I know Cheetah pretty well):

------------------- quote start -----------
Cheetah, OTOH, compiles each template to a Python class! This is much slower, and in my experience brittle -- on my first attempt I introduced a syntax error in the template that caused a Python syntax error in the resulting Python class, which was hard to debug. It also seems overkill, and I worry that it might cause security problems -- given that the compiler isn't too smart (see above) I could see a malicious template author "breaking out" of the templating languages and invoking unauthorized Python code. Now, I wouldn't let people I don't trust edit templates on my website anyway, but it appears to be a common pattern that certain people are allowed to edit templates but not code. Cheetah blurs the distinction a little too much for my comfort.
------------------- quote end -----------

Ok the first time the compilation happens it may well be slower, but then the resulting class bytecode is cached and it's optimally written to execute just the needed steps to output the html (or whatever else target).

For example if you disable fitlers, the filter calls will go away from the compiled bytecode, and it won't cause anymore overhead.

I would like eventually see Cheetah speaking in terms of twisted deferreds for example, and that will be only a "compilation" cost. Clearly not everyone will ever understand async code and the deferreds mechanism, so it would be bad if the deferred would cause overhead to people not using them (they already pay an hefty price with overkill amount of stacks and therad related overhead when a thin data structure passed to epoll could achieve the same). So the compilation would generate a different python class (with a different html rendering method) depending if you enable the deferred-speak or not. This is the direction I want to see CPUShare-Twisted (http://www.cpushare.com/twisted) going.

So to me the compilation cost seems an huge speed benefit, the opposite of what you described above (especially when working with pre-compiled templates, though I don't use them).

I think other languages like Nevow tries to do some parse-caching, but
regardless of the caching it does to avoid reparsing xml every time, I
measured nevow is close to 10 times slower in the rendering than Cheetah (sure a lot slower than 5 times, measured on ppc64 and x86-64 with python2.4),
and it's a lot more compicated and less flexible. I can't speak for Django performance since I never tried it,
but I'd be surprised if Django can be any faster than Cheetah (starting from the second rendering invocation after the compiled bytecode is cached by the class.hash), did you run some benchmark comarping Django to Cheetah?

About the security point it will definitely cause security problems if you allow untrusted people to edit the templates.
This is because you can import any python module and execute any python
code from the template. You can't import a template if you don't trust
it. But is this any different from php where code and html are mixed in
the first place?

I'm using Cheetah successfully so far for KLive and CPUShare and I'm really happy about the ~ten fold performance boost in html rendering I got.

I know if using python performance should not be very relevant, but it really is, performance is always relevant. One of the reasons to use python (or ruby or other similar languages) instead of C is to decrease the time-to-market, but if with the same developer-time you can render html 10 times faster and divide the number of servers you need by 10, that's very significant.

On the debugging side I never had significant problems with Cheetah, the only screwed thing I get is the fact Cheetah shows the line of the exception in the compiled class, but I never get to see the source of the compiled class because I don't use precompiled templates. But the exception also provides more info and not only the exception line, so I never had problems to fix things. I also like the strict behavior where if a parameter is missing an exception is raised.

On the debugging front the only thing that I really miss and that everyone would get benefit from, is not related to Cheetah but it's a very python thing. That is the nevow exception handler in html inside the browser you can see it here:

http://divmod.org/trac/browser/trunk/Nevow/nevow/failure.py

See the formatFailure class. I've seen posts of people moving from nevow to CheeryPy also feeling the lack of this piece of code. That is a function that extracts all local variables and shows them along the exception in all frames. That really should be generalized, de-stanned, and made generic somehow, so that it works for normal exceptions too and not only for twisted failure objects (and with html and text targets, I work with test normally since showing exceptions in the browser is unsafe).

I'm probably going eventually to implement something similar in my twisted-cpushare project as a standard API eventually, and I'll use it to send me all the relevant debugging info by email and sms when an exception triggers (currently I only get the exception, without local variables and context).

One last bit: I also like the fact how Cheetah is a standalone lib and self contained.

Thanks everyone for these open source products.

Johnny Stovall

Posts: 5
Nickname: oouc
Registered: Jan, 2008

Re: Django vs. Cheetah: 1-0 Posted: Jan 27, 2008 10:34 PM
Reply to this message Reply
I would like to see some hard facts about Django, Cheetah, and other web frameworks. Perhaps someone would be so kind as to fill in the spreadsheet below and post it to this list and to oouc Curvey symbol yahoo period com

,"Sw ProductName & Description:",,,,,,,,,,,,,
,"Hw Platform 1 Description=*nix...",,"Hw Platform 2 Description=Win...",,,,,,,,,,,
,"PageSizeOn Platform 1","PageSizeOn Platform 1","PageSizeOn Platform 2","PageSizeOn Platform 2","PageSizeOn Platform 1","PageSizeOn Platform 1","PageSizeOn Platform 1","PageSizeOn Platform 1","PageSizeOn Platform 2","PageSizeOn Platform 2","PageSizeOn Platform 1","PageSizeOn Platform 1","PageSizeOn Platform 2","PageSizeOn Platform 2"
,"102400 bytes Bandwidth=","102400 bytes Ram=","102400 bytes Bandwidth=","102400 bytes Ram=","256000 bytes Bw=","256000 bytes Ram=","512000 bytes Bw=","512000 bytes Ram=","512000 bytes Bw=","512000 bytes Ram=","1024000 bytes Bandwidth=","1024000 bytes Ram=","1024000 bytes Bandwidth=","1024000 bytes Ram="
"10 PageViews Per Hour",,,,,,,,,,,,,,
"100 PageViews Per Hour",,,,,,,,,,,,,,
"500 PageViews/Hour",,,,,,,,,,,,,,
"1000 PageViews/Hour",,,,,,,,,,,,,,
"etc.",,,,,,,,,,,,,,

Flat View: This topic has 86 replies on 6 pages [ « | 3  4  5  6 ]
Topic: Django vs. Cheetah: 1-0 Previous Topic   Next Topic Topic: ScalaTest 0.9 Released
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use