Web development with Python 3.1

Dotan Cohen dotancohen at gmail.com
Fri Oct 30 14:23:45 CET 2009

>> Look at this "templating code":
>> {% for entry in blog_entries %}
>>    <h2>{{ entry.title }}</h2>
>>    <p>{{ entry.body }}</p>
>> {% endfor %}
> What's the problem ? Simple, clear and obvious.

It is clear and obvious. But it has the "template engine" duplicating
a function that Python has built in. My goal is to learn reusable
Python (reusable for non-web projects). My goal is not to find the
quickest way to a website.

>> Why would I want to learn that when Python already has a real for
>> loop ?
> If you know even 101 Python, understanding the above code shouldn't be such
> a great challenge !-)

It is not a great challenge, but it is redundant. Learning Django
language won't help me learn Python any more than learning PHP would.
So going from PHP to Django is pointless.

>> I know HTML, and I have a goal of learning Python for it's
>> reusability (desktop apps, for instance).
> Using templates instead of harcoding HTML in the applicative code actually
> plays a big part when it comes to reusability.

I meant reusable knowledge, not reusable code.

> Telling Django's template
> loader where to look for templates is just a matter of configuration, so
> using templates you can segment your whole project in small, possibly
> reusable apps - then in another project where you need the same features but
> with a totally different presentation, it's just a matter of writing
> project-specific templates. Quite a few django apps work that way, and they
> really save you a LOT of time. This wouldn't be possible using your beloved
> antipattern...

I think that the time that I invest codng in Python as opposed to
Django Template Language is time well spent.

>> I don't want to learn some
>> "templating language" that duplicates what Python already has built
>> in!
> Then use Mako - it uses plain Python to manage the presentation logic. And
> if you go for Mako, then you might as well switch to Pylons. Great framework
> too (better than Django on some parts FWIW), but you'll probably need much
> more time to be fully productive with it (power and flexibility come with a
> price...).

Now we're talking! I will look further into Pylons and Mako.

> Now wrt/ "why having a distinct templating language", there are pros and
> cons. On the pros side, having a language that is clearly restricted to
> presentation logic prevents you (and anyone else working on the project -
> and sometimes you have to deal with well-below-average guys in your team) to
> put anything else than presentation logic in the templates.

I don't expect to ever have a "team", but as a hobbiest and not a
coder I myself am "below average". I promise you that _will_improve_,

> Bless me for I have sinned - sometimes, when you're tired and under pressure
> to deliver in time, it's tempting to add a Q&D hack in the presentation part
> instead of DoingTheRightThing(tm). This can save you some "precious" minutes
> now. The problem is that usually your boss won't give you the resources to
> clean up this mess once you delivered, and next time you have to work on
> this project - fix or evolution - you have to deal with this hack. Then with
> another, yet another, until your code is nothing more than an unmaintainable
> heap of junk. Been here, done that, bought the T-shirt :(
> Also remember that most of the time, a web app is a team effort, and even if
> *you* don't fail to temptation, others may do so. And finally, the team
> usually involve "HTML coders" - who, despite what the name seems to imply,
> are usually skilled enough to handle the presentation logic by themselves,
> so you the application programmer can concentrate on applicative code. From
> experience, they usually prefer a simple straightforward - even if somehow
> restricted - templating language.
> Now, as far as I'm concerned, having Mako instead of Django's templates
> wouldn't bother me at all. But Django has it's own template system, which
> from experience get the job done (believe me, there are way worse
> alternatives), and the overall qualities and features of the whole framework
> are IMHO enough to justify learning it's templating language.

I see. I will have to spend some time with each to decide, though.

>> I think that I will use the HTTP-abstraction features of Django, but
>> disregard the templates. My code might be uglier, but the knowledge
>> will be transferable to other projects. My ultimate goal is not to
>> make the latest greatest website. My ultimate goal is to port my
>> perfectly functional website to a language that will benefit me by
>> knowing it.
> Given the restricted and rather unintersting nature of pure presentation
> logic, you won't learn much from this part of the project anyway. You'd
> probably learn way more using Django's templates and learning how to write
> your own template tags. Or if you prefer Mako / Pylons, learning to make
> proper use of Mako's advanced features. But one thing is clear - if you
> persist on applying your favorite antipattern, you'll just waste more of
> your time. Your choice, as usual...

The point is that I want to use only _Python_ features, not
Django/Mako/whatever features. However I am aware that some things I
should not touch for security reasons. That is why I want a framework:
to provide the security aspects of things like converting UTF-8,
database escaping, etc.

> My 2 cents...

A very valuable 2 cents. Thanks.

Dotan Cohen


More information about the Python-list mailing list