Web development with Python 3.1

[Bruno Desthuilliers]

Dotan Cohen a écrit :
>>> 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.

Please correct me if I'm wrong, but you did learn HTML, CSS and SQL, 
didn't you ? How do any of these languages relates to Python ?-)


> 
>>> 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

<pedantic>
Django's templating language, actually
</pedantic>

> won't help me learn Python any more than learning PHP would.
> So going from PHP to Django is pointless.

Please get out of the "server page" mindset. Templates are just that : 
templates. Period. You don't use templates to write your *applicative* code.

> 
>>> 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.

There's very few "reusable knowledge" to be gained from templating code 
anyway- even if using a "python-based" template system like Mako. Unless 
you think doing a loop or a conditional are things you need to learn ?-)

> 
>> 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.

Then write your own templating system - and your own framework FWIW !-)

> 
>>> 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. 
>>
> 
> Now we're talking! I will look further into Pylons and Mako.

Beware that the above comments about how less there's to learn from the 
templates code still apply - basically, the "programming" part of a 
template is restricted to simple branching, iterations, and variable 
substitution.

> 
>> 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",

Possibly not. But as strange as it migh be, there are other peoples that 
do, and most of these frameworks are written by professional web 
programmers.

>> 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.

That's usually the best thing to do - take a couple days doing the 
tutorials, and choose the one that fits your brain.

>> 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.

If so, you shouldn't use *any* third-part libs, and possibly not even 
the stdlib.

More seriously : reinventing the wheel - unless for educational purposes 
- is not really pythonic. If what you want is to learn, write your own 
framework, template system, form handling etc... You'll very certainly 
find out that they suck big time compared to existing projects, but 
you'll learn _at least_ one thing: that writing a sensible non-trivial 
framework or lib is *hard*.

Once again, been here, done that...

> 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,

from what and to what ?-)

string / unicode encoding and decoding is a builtin Python feature.

> database escaping, 

Already provided by any DB-API compliant connector, at least if 
correctly used.

Now there's *much* more in security (specially when doing web 
programming) than this...