>>> 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
> 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...
> It is clear and obvious. But it has the "template engine" duplicating > a function that Python 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.
I took a look a both yesterday. They are both generic text templating systems that seem to pretty much do the same thing. I suspect you will prefer Mako since it avoids duplicating Python's comtrol structures. But I think it worthwhile to look at both anyway since doing so will help to separate the concepts from the particular implementations.
My take on them is this: when text mixes code that is meant to be interpreted and text data meant to be taken literally, some means must be devised to distinguish the two. In programs files, the code is left unquoted and the text data is quoted. In template files, the marking is reversed: the literal text is left unquoted and the code *is* quoted. In Mako, expressions are quoted with braces ({...}), single statements with '%' prefix, and multiple statements as well as Mako tags with <% ...>.
>> 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 ?-)
HTML and CSS yes, but just enough SQL to fake it. None of those languages relate to Python, each language performs a different function. However, the template language looks completely redundant as it duplicates functionality of the language that I intend to learn.
>> 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 understand that.
>> 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 ?-)
I would say that one needs to know how to do a for loop in Python, in order to program in Python!
>>> 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.
I see.
>> 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.
I therefore counter that these frameworks were designed for people unlike myself, which easily explains my resistance to them.
>> 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.
THat is going just a bit far!
> 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*.
Actually, I konw just how hard it is. PHP and some C in university.
>> 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 ?-)
Into and out of the database.
> string / unicode encoding and decoding is a builtin Python feature.
I know, but I need to play with it a bit before I become comfortable with how it is handled.
>> 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...
Of course. But these are the relevant issues for Python.
> I took a look a both yesterday. They are both generic text templating > systems that seem to pretty much do the same thing. I suspect you will > prefer Mako since it avoids duplicating Python's comtrol structures. But I > think it worthwhile to look at both anyway since doing so will help to > separate the concepts from the particular implementations.
> My take on them is this: when text mixes code that is meant to be > interpreted and text data meant to be taken literally, some means must be > devised to distinguish the two. In programs files, the code is left unquoted > and the text data is quoted. In template files, the marking is reversed: the > literal text is left unquoted and the code *is* quoted. In Mako, expressions > are quoted with braces ({...}), single statements with '%' prefix, and > multiple statements as well as Mako tags with <% ...>.
>>> 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 ?-)
> HTML and CSS yes, but just enough SQL to fake it. None of those > languages relate to Python, each language performs a different > function. However, the template language looks completely redundant as > it duplicates functionality of the language that I intend to learn.
Templating languages serve a different, highly specialized purpose. They may have similar flow constructs, but the context and specializations matter a lot. Use the right language for the job. Sometimes the job is a weird mix of concerns and requires a weird mix of constructs to be convenient. If you're writing web apps, you should learn a templating language. If you're primarily concerned with learning Python and nothing else, you should find a different kind of project.
But if you insist, you may be interested in Breve:
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
> >> While I know that to be true in the general sense, from what I've > >> looked at Django and other frameworks it seems that the web frameworks > >> push the coder to use templates, not letting him near the HTML.
> >> For instance, I was looking for a class / framework that provided a > >> proven method of decoding cookies (setting them is no problem), > >> decoding POST and GET variables, escaping variables for safe entry > >> into MySQL, and other things. Django and the other frameworks seem to > >> force the user to use templates. I just want the functions, and to > >> print the HTML as stdout to the browser making the request. I had to > >> settle on PHP to do this, which admittedly is what PHP was invented to > >> do. However, for obvious reasons, I would have prefered to code in > >> Python. In fact, I still would.
> > I should probably expand on this:
> > How can I get an array with all the GET variables in Python? > > How can I get an array with all the POST variables in Python? > > How can I get an array with all the COOKIE variables in Python? > > How can I get the request URI path (everything after > >http://[www.?]example.com/)?
> > That's all I want: no templates and nothing between me and the HTML. > > The HTTP headers I can output to stdout myself as well.
> Again: if you insist on doing everything yourself - then of course any > library or framework isn't for you.
> But then do you deal with headers correctly? Do you respect character > encodings? Form-encodings? Is your generated HTML valid? Are > timestamp-formats generated according to RFCs for your cookies? Do you > parse content negotiation headers?
> I think you underestimate the task it is to make a webapplication good. > And even if not, what you will do is ... code your own webframework. > Because there is a lot of boilerplate otherwis. If that's a > learning-experience your after, fine.
> Besides, yes, you can get all these things nonetheless. You just don't > need them most of the time.
> And at least pylons/TG2 lets you return whatever you want instead, as a > string. Not via "print" though - which is simply only for CGI, and no > other means (e.g. mod_wsgi) of python-web-programming.
> Diez
notmm uses Python 2.6 and will probably work just fine with Python 3000.
> On Oct 28, 5:16 am, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> > Dotan Cohen schrieb:
> > >> While I know that to be true in the general sense, from what I've > > >> looked at Django and other frameworks it seems that the web frameworks > > >> push the coder to use templates, not letting him near the HTML.
> > >> For instance, I was looking for a class / framework that provided a > > >> proven method of decoding cookies (setting them is no problem), > > >> decoding POST and GET variables, escaping variables for safe entry > > >> into MySQL, and other things. Django and the other frameworks seem to > > >> force the user to use templates. I just want the functions, and to > > >> print the HTML as stdout to the browser making the request. I had to > > >> settle on PHP to do this, which admittedly is what PHP was invented to > > >> do. However, for obvious reasons, I would have prefered to code in > > >> Python. In fact, I still would.
> > > I should probably expand on this:
> > > How can I get an array with all the GET variables in Python? > > > How can I get an array with all the POST variables in Python? > > > How can I get an array with all the COOKIE variables in Python? > > > How can I get the request URI path (everything after > > >http://[www.?]example.com/)?
> > > That's all I want: no templates and nothing between me and the HTML. > > > The HTTP headers I can output to stdout myself as well.
> > Again: if you insist on doing everything yourself - then of course any > > library or framework isn't for you.
> > But then do you deal with headers correctly? Do you respect character > > encodings? Form-encodings? Is your generated HTML valid? Are > > timestamp-formats generated according to RFCs for your cookies? Do you > > parse content negotiation headers?
> > I think you underestimate the task it is to make a webapplication good. > > And even if not, what you will do is ... code your own webframework. > > Because there is a lot of boilerplate otherwis. If that's a > > learning-experience your after, fine.
> > Besides, yes, you can get all these things nonetheless. You just don't > > need them most of the time.
> > And at least pylons/TG2 lets you return whatever you want instead, as a > > string. Not via "print" though - which is simply only for CGI, and no > > other means (e.g. mod_wsgi) of python-web-programming.
> > Diez
> notmm uses Python 2.6 and will probably work just fine with Python > 3000.
> Cheers,
> Etienne
> P.S - We all don't think in the same box.
"I am free, no matter what rules surround me. If I find them tolerable, I tolerate them; if I find them too obnoxious, I break them. I am free because I know that I alone am morally responsible for everything I do." -- Robert A. Heinlein
>> notmm uses Python 2.6 and will probably work just fine with Python >> 3000.
The only reference to "notmm" that I could find in Google was this thread!
> "I am free, no matter what rules surround me. If I find them > tolerable, I tolerate them; if I find them too obnoxious, I break > them. I am free because I know that I alone am morally responsible for > everything I do." -- Robert A. Heinlein
Heinlein said that? It's been a long time since I've read Heinlein, and his quotes are as vivid as his books.
With respect to to original question regarding web frameworks + database and Python 3, all the following have been available for Python 3 since the day Python 3.0 was released:
> On Nov 5, 2:23 pm, Bruno Desthuilliers <bruno. > 42.desthuilli...@websiteburo.invalid> wrote: >> rustom a écrit :
>>> On Oct 30, 6:23 pm, Dotan Cohen <dotanco...@gmail.com> wrote: >>>> The point is that I want to use only _Python_ features, not >>>> Django/Mako/whatever features. >>> Pure python has a builtin templating system -- its called % >> Poor man's template... It only do variable substitutions - no branching >> nor iteration (and let's not talk about macros, inclusions, filters etc).
42.desthuilli...@websiteburo.invalid> wrote: > rustom a écrit :
> > On Nov 5, 2:23 pm, Bruno Desthuilliers <bruno. > > 42.desthuilli...@websiteburo.invalid> wrote: > >> rustom a écrit :
> >>> On Oct 30, 6:23 pm, Dotan Cohen <dotanco...@gmail.com> wrote: > >>>> The point is that I want to use only _Python_ features, not > >>>> Django/Mako/whatever features. > >>> Pure python has a builtin templating system -- its called % > >> Poor man's template... It only do variable substitutions - no branching > >> nor iteration (and let's not talk about macros, inclusions, filters etc).
> Still poor man's template. Just don't hope to do any realworld web > templating with this.
This is said in the context of some of Dotan's quotes eg.
> I am not a programmer by trade, only by hobby. > I want to learn Python not Django
etc
Python is generally imperative. Templates are by and large declarative.
To get this 'Aha' across to him (remember he said hes a mechanical engineer) is (IMHO) more important than converting him to some moral high ground of reusability or some other nice software engineering jargon.
mario ruggier wrote: > With respect to to original question regarding web frameworks + > database and Python 3, all the following have been available for > Python 3 since the day Python 3.0 was released:
> Evoque, state-of-the-art templating engine > http://pypi.python.org/pypi/evoque/ > (this one is available for py3.0 since a little later, 21-jan-2009)
> All the above also runs on python 2.4 (thru to python 3)
|
