Web development with Python 3.1
Alan Harris-Reid
I am very much new to Python, and one of my first projects is a simple
data-based website. I am starting with Python 3.1 (I can hear many of
you shouting "don't - start with 2.6"), but as far as I can see, none of
the popular python-to-web frameworks (Django, CherryPy, web.py, etc.)
are Python3 compatible yet.
So, what can I use to start my web programming experience using 3.1?
Any help would be appreciated.
Alan
Paul Rubin
Does it occur to you that the unavailability of those frameworks is
part of the REASON they say to use 2.x? Have you answered your own
question?
Anyway, for simple web programming, frameworks are not worth the
hassle. Just use the cgi module.
If you want to use a framework, well, you are the one who decided to
zoom off into the 3.1 wilderness before the framework developers got
there. If you're an experienced programmer in other languages and
you're determined to use a framework, maybe a worthwhile Python
learning project would be to help port your favorite framework to 3.1.
exa...@twistedmatrix.com
>
>I am very much new to Python, and one of my first projects is a simple
>data-based website. I am starting with Python 3.1 (I can hear many of
>you shouting "don't - start with 2.6"), but as far as I can see, none
>of the popular python-to-web frameworks (Django, CherryPy, web.py,
>etc.) are Python3 compatible yet.
>
>So, what can I use to start my web programming experience using 3.1?
>
don't - start with 2.6
>Alan
>
>--
>http://mail.python.org/mailman/listinfo/python-list
Chris Withers
> I can vouch for what Paul says. I started in Python 3 years ago, and I
> did so with a web application (still working on it!). I'm using the cgi
> approach, and it certainly teaches you the concepts. I fail to see how
> starting with a framework is a good idea if you don't know how the
> frameworks work (or what they're actually doing). It would be a bit like
> doing a web page in Dreamw***er and thinking you understand HTML/CSS.
I couldn't agree less. Using the CGI module is more akin to trying to
write Dreamweaver when you want to build a static website...
Just use 2.6 and pick a framework of your choice. From what the OP
described, Django or Pylons would fit the bill well.
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
Echo
the 2to3 tool on it. It is a very lightweight framework. CherryPy 3.2
also runs on python 3.x
I don't know if there are any others.
On Sun, Oct 25, 2009 at 7:52 PM, Alan Harris-Reid
<al...@baselinedata.co.uk> wrote:
>
> I am very much new to Python, and one of my first projects is a simple
> data-based website. I am starting with Python 3.1 (I can hear many of you
> shouting "don't - start with 2.6"), but as far as I can see, none of the
> popular python-to-web frameworks (Django, CherryPy, web.py, etc.) are
> Python3 compatible yet.
>
> So, what can I use to start my web programming experience using 3.1?
>
> Any help would be appreciated.
>
> Alan
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
-Brandon Singer
Alan Harris-Reid
> don't - start with 2.6
Thought you might say that ;-)
Regards,
Alan
On 25 Oct, 11:52 pm, al...@baselinedata.co.uk wrote:
>
>I am very much new to Python, and one of my first projects is a simple
>data-based website. I am starting with Python 3.1 (I can hear many of
>you shouting "don't - start with 2.6"), but as far as I can see, none
>of the popular python-to-web frameworks (Django, CherryPy, web.py,
>etc.) are Python3 compatible yet.
>
>So, what can I use to start my web programming experience using 3.1?
>
>Any help would be appreciated.
don't - start with 2.6
>Alan
>
>--
>http://mail.python.org/mailman/listinfo/python-list
Aaron Watters
Don't. use python 2.6 with WHIFF :)
http://aaron.oirt.rutgers.edu/myapp/GenBankTree/index
http://whiff.sourceforge.net
-- Aaron Watters
===
It gotta be rock-roll music
if you wanna dance with me
if you wanna dance with me
Dotan Cohen
Does the OP need to work with cookies or other http-specific features?
In fact, other than cookies, what http-specific features exist? Does
Python have a built-in framework for making available GET and POST
variables? Database queries should be no different than in other
Python apps.
--
Dotan Cohen
Diez B. Roggisch
> Why the push to use a framework, and why the resistance from the OP?
>
> Does the OP need to work with cookies or other http-specific features?
> In fact, other than cookies, what http-specific features exist?
declarative mapping of urls to code, of code to templates, abstracting away
the details of GET and POST, validating and decoding parameters, especially
if these become larger repetitive structures like several addresses of a
user, re-rendering invalid form-data, working with HTML or JSON as output,
managing transactions, providing a error-reporting-infrastructure
The list continues.
> Does
> Python have a built-in framework for making available GET and POST
> variables? Database queries should be no different than in other
> Python apps.
Yes, in the end of the day, it's all python.
Diez
"Martin v. Löwis"
> data-based website. I am starting with Python 3.1 (I can hear many of
> you shouting "don't - start with 2.6"), but as far as I can see, none of
> the popular python-to-web frameworks (Django, CherryPy, web.py, etc.)
> are Python3 compatible yet.
That's not entirely true, see
http://wiki.python.org/moin/PortingDjangoTo3k
Regards,
Martin
Dotan Cohen
Apache does this, unless I am misunderstanding you.
> of code to templates
Those who code in HTML don't need this. In any case it's not hard to
call a function in a class that writes the HTML before the content,
then write the content, then call another function that writes the
HTML after the content. This is how my sites are run, though in PHP
instead of Python. No prepackaged templates.
> abstracting away
> the details of GET and POST
GET is easy, just parse the HTTP request. I don't know how much of a
problem POST would be.
> validating and decoding parameters, especially
> if these become larger repetitive structures like several addresses of a
> user
This falls under database, cookies, or HTTP request parsing. Or am I
misunderstanding something again?
> re-rendering invalid form-data
Just add it into the HTML.
> working with HTML or JSON as output,
Same as writing to stdout, just output the HTTP headers first.
> managing transactions, providing a error-reporting-infrastructure
>
This does not differ from regular (non-web) Python coding.
> The list continues.
>
I would really like to know what else. So far, I am not convinced that
a framework offers anything that is not already easily accomplished in
Python.
"Martin v. Löwis"
> data-based website. I am starting with Python 3.1 (I can hear many of
> you shouting "don't - start with 2.6"), but as far as I can see, none of
> the popular python-to-web frameworks (Django, CherryPy, web.py, etc.)
> are Python3 compatible yet.
That's not entirely true, see
http://wiki.python.org/moin/PortingDjangoTo3k
Regards,
Martin
geremy condra
>> declarative mapping of urls to code
>
> Apache does this, unless I am misunderstanding you.
>
>
>> of code to templates
>
> Those who code in HTML don't need this. In any case it's not hard to
> call a function in a class that writes the HTML before the content,
> then write the content, then call another function that writes the
> HTML after the content. This is how my sites are run, though in PHP
> instead of Python. No prepackaged templates.
>
>> the details of GET and POST
>
> GET is easy, just parse the HTTP request. I don't know how much of a
> problem POST would be.
>
>
>> if these become larger repetitive structures like several addresses of a
>
> This falls under database, cookies, or HTTP request parsing. Or am I
> misunderstanding something again?
>
>
>> re-rendering invalid form-data
>
> Just add it into the HTML.
>
>
>
>
>
>>
>
>
>
>> The list continues.
>>
>
> I would really like to know what else. So far, I am not convinced that
> a framework offers anything that is not already easily accomplished in
> Python.
Using a framework helps to ensure that your code is easy to maintain.
DRY isn't about saving time now, its about saving time six months
from now.
Geremy Condra
Dotan Cohen
I see, that is a good point. With someone else (the framework
maintainers) worrying about maintaining function such as HTTP request
parsers, a lot of work won't have to be [re]done.
> DRY isn't about saving time now, its about saving time six months
> from now.
>
I suppose in this case it's DRTW (don't reinvent the wheel) but the
same principle applies.
Aaron Watters
...
> Yes, in the end of the day, it's all python.
For me, in the end of the day, it's all java or PHP.
But I'm working on that. For my purposes the "frameworks"
don't really help much. That's why I built WHIFF :).
http://aaron.oirt.rutgers.edu/myapp/docs/W1100_2200.TreeView
-- Aaron Watters
===
If all you got is lemons, make lemonade.
-- anon.
geremy condra
>> Using a framework helps to ensure that your code is easy to maintain.
>
> I see, that is a good point. With someone else (the framework
> maintainers) worrying about maintaining function such as HTTP request
> parsers, a lot of work won't have to be [re]done.
>
>
>> DRY isn't about saving time now, its about saving time six months
>> from now.
>>
>
> I suppose in this case it's DRTW (don't reinvent the wheel) but the
> same principle applies.
Well, yes- but it's also DRY, and while DRTW (like the acronym, btw)
helps to prevent your code from being unreadable to someone else,
DRY helps to ensure that when you have to change something you
don't have to worry about changing it in 37 and a half other places
at the same time. Especially given how notoriously difficult it is to
do automated testing for web development, that's essential.
Geremy Condra
Dotan Cohen
> helps to prevent your code from being unreadable to someone else,
> DRY helps to ensure that when you have to change something you
> don't have to worry about changing it in 37 and a half other places
> at the same time. Especially given how notoriously difficult it is to
> do automated testing for web development, that's essential.
>
That's what classes are for, no? Reuse code. I fail to see how using a
framework would reduce the need to use classes, provided that the need
exists.
geremy condra
>> Well, yes- but it's also DRY, and while DRTW (like the acronym, btw)
>> helps to prevent your code from being unreadable to someone else,
>> DRY helps to ensure that when you have to change something you
>> don't have to worry about changing it in 37 and a half other places
>> at the same time. Especially given how notoriously difficult it is to
>> do automated testing for web development, that's essential.
>>
>
> That's what classes are for, no? Reuse code. I fail to see how using a
> framework would reduce the need to use classes, provided that the need
> exists.
...frameworks use classes. They just don't make you write all of them.
Geremy Condra
Diez B. Roggisch
>> Well, yes- but it's also DRY, and while DRTW (like the acronym, btw)
>> helps to prevent your code from being unreadable to someone else,
>> DRY helps to ensure that when you have to change something you
>> don't have to worry about changing it in 37 and a half other places
>> at the same time. Especially given how notoriously difficult it is to
>> do automated testing for web development, that's essential.
>>
>
> That's what classes are for, no? Reuse code. I fail to see how using a
> framework would reduce the need to use classes, provided that the need
> exists.
>
A webframework is *written* in python. Your whole line of argumentation
boils down to "I can write things myself in python, why use
libraries/frameworks". Yes. You can also delete your standard-lib, and
code everything in there yourself - with the same argument.
Using a framework is about proven solutions for common problems, letting
you focus on working on your actual application code.
Diez
John Nagle
> I am very much new to Python, and one of my first projects is a simple
> data-based website. I am starting with Python 3.1
Until MySQLdb gets ported to something later than Python 2.5, support
for a "data-based web site" probably has to be in Python 2.5 or earlier.
The C module situation for Python 3.x still isn't very good.
Realistically, the production version of Python is 2.5. This process
is taking long enough that I'm worried that Python 3.x could do for
Python what Perl 6 did for Perl - provide an upgrade path that nobody
takes.
HTMLTemplate ("http://py-templates.sourceforge.net/htmltemplate/index.html")
is a minimal templating system for fill-in-the-blanks template work in Python.
Actually, if you have HTMLTemplate, FCGI, and MySQLdb, you have enough to
do a back-end database.
There are some advantages to libraries (you call them) over "frameworks"
(they call you) if you're doing something unusual. Frameworks are more
useful if you're doing yet another "Web 2.0" web site.
John Nagle
Paul Rubin
> Until MySQLdb gets ported to something later than Python 2.5, support
> for a "data-based web site" probably has to be in Python 2.5 or earlier.
Even 2.6 is too bleeding-edge? Uh oh, Fedora 12 is shipping it.
Dotan Cohen
> boils down to "I can write things myself in python, why use
> libraries/frameworks". Yes. You can also delete your standard-lib, and code
> everything in there yourself - with the same argument.
>
> Using a framework is about proven solutions for common problems, letting you
> focus on working on your actual application code.
>
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.
Dotan Cohen
> 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.
Dotan Cohen
>
Fedora has traditionally been known as a bleeding edge distro.
Diez B. Roggisch
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
Diez B. Roggisch
> Alan Harris-Reid wrote:
>> I am very much new to Python, and one of my first projects is a simple
>> data-based website. I am starting with Python 3.1
>
> Until MySQLdb gets ported to something later than Python 2.5, support
> for a "data-based web site" probably has to be in Python 2.5 or earlier.
The usual FUD from you.
http://pypi.python.org/pypi/MySQL-python/1.2.3c1
And of course there are other alternatives to databases, which happily
run under 2.6 as well.
Diez
Bruno Desthuilliers
>> declarative mapping of urls to code
>
> Apache does this, unless I am misunderstanding you.
Using url rewriting ? Yes, fine. Then tell me how you implement
"reverse" url generation (like Django or Routes do).
>
>> of code to templates
>
> Those who code in HTML don't need this.
???
> In any case it's not hard to
> call a function in a class that writes the HTML before the content,
> then write the content, then call another function that writes the
> HTML after the content.
Hmmm, yummy ! And SO maintainable...
> This is how my sites are run, though in PHP
> instead of Python. No prepackaged templates.
PHP *is* a template language.
(snip)
> I would really like to know what else. So far, I am not convinced that
> a framework offers anything that is not already easily accomplished in
> Python.
Given that we're talking about Python frameworks, it seems obvious that
what they do can be accomplished in Python. Now the question is how much
you like to write the same boring and error-prone boilerplate code
project after project...
Bruno Desthuilliers
>> Well, yes- but it's also DRY, and while DRTW (like the acronym, btw)
>> helps to prevent your code from being unreadable to someone else,
>> DRY helps to ensure that when you have to change something you
>> don't have to worry about changing it in 37 and a half other places
>> at the same time. Especially given how notoriously difficult it is to
>> do automated testing for web development, that's essential.
>>
>
> That's what classes are for, no? Reuse code.
Nope. "classes" are an artifact of one possible approach of OOP, period.
> I fail to see how using a
> framework would reduce the need to use classes,
Why should it ?
Bruno Desthuilliers
>> A webframework is *written* in python. Your whole line of argumentation
>> boils down to "I can write things myself in python, why use
>> libraries/frameworks". Yes. You can also delete your standard-lib, and code
>> everything in there yourself - with the same argument.
>>
>> Using a framework is about proven solutions for common problems, letting you
>> focus on working on your actual application code.
>>
>
> 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.
Well... there must be a reason, for sure... No ?
> Django and the other frameworks seem to
> force the user to use templates.
Not at all. Nothing prevents you from shooting yourself in the foot and
generating HTML "by hand" in your view functions (or request handler
methods etc, depending on the framework). This is just plain stupid wrt/
readability, maintainability, reuse and whatnot, but hey, if you want
to waste your time, please do. As far as i'm concerned, I'm very happy
to let the HTML coder write the HTML part and the application programmer
write the applicative part - even when I end up wearing both caps.
> 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,
Why so ? Almost any programming language can do CGI.
Bruno Desthuilliers
> Alan Harris-Reid wrote:
>> I am very much new to Python, and one of my first projects is a simple
>> data-based website. I am starting with Python 3.1
>
> Until MySQLdb gets ported to something later than Python 2.5, support
> for a "data-based web site" probably has to be in Python 2.5 or earlier.
hem....
bruno@bruno:~$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb
>>> MySQLdb
<module 'MySQLdb' from
'/var/lib/python-support/python2.6/MySQLdb/__init__.pyc'>
You said ???
(snip)
> Frameworks are more
> useful if you're doing yet another "Web 2.0" web site.
I beg to disagree.
Mikhail M.Smagin
On Wed, 28 Oct 2009 10:26:22 +0200
Dotan Cohen <dotan...@gmail.com> wrote:
> 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.
$python
>>help(cgi)
>>help(cgitb)
>>help(Cookie)
>>help(urlparse)
>>help(os.environ)
GET variables:
-------------------------------------------------------------------------
import os,cgi
if os.environ.has_key('QUERY_STRING'):
getv = cgi.parse_qs(os.environ['QUERY_STRING'])
print getv.keys()
Other examples is very simple too...
--
Mikhail M.Smagin <m...@x3.dp.ua>
Dotan Cohen
>>
>> 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.
>
I insist on handling the HTML myself. As for converting the request
variables into Python variables, if a class/framework makes that
easier then I would gladly use it. My question was serious. How can I
do those things?
> But then do you deal with headers correctly?
Yes, so far as I know. This is actually simpler than the HTML, just be
careful not to output two newline characters in sequence (thereby
ending the header).
> Do you respect character
> encodings?
Yes! UTF-8 from database to scripting language to HTTP request.
> Form-encodings?
Yes, UTF-8 the in the other direction. However, as form data can be
spoofed, I would like a function that checks it. Does Python have such
a function? What class does?
> Is your generated HTML valid?
Naturally, even though this is not a Python issue.
> Are
> timestamp-formats generated according to RFCs for your cookies?
Yes, this is not a problem. Is there some gothcha that I am unaware of?
> Do you parse
> content negotiation headers?
>
No. I hate sites that do that. If the page is available in another
language, their is a link in the corner.
> I think you underestimate the task it is to make a webapplication good.
Probably, but that would not depend on the scripting language. I make
bad webapplications in PHP too!
> And
> even if not, what you will do is ... code your own webframework.
That is why I am looking for a class that handles the backend stuff,
but lets _me_ handle the HTML.
> 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.
>
I am trying to follow you here. What is "return whatever you want"?
Return HTML to stdout to be sent to the browser?
Dotan Cohen
> Dotan Cohen a écrit :
>>>
>>> declarative mapping of urls to code
>>
>> Apache does this, unless I am misunderstanding you.
>
> Using url rewriting ? Yes, fine. Then tell me how you implement "reverse"
> url generation (like Django or Routes do).
I have no idea what reverse url generation is. I assume that the user
will call http://example.com/path/to/script.py?var1=hello&var2=world
script.py would live in /home/user/site-name/public_html/path/to/
>>> of code to templates
>>
>> Those who code in HTML don't need this.
>
> ???
>
I would prefer to output everything from <html> to </html> with print
statements. I don't want some framework wrapping my output in tags, I
want the tags to be part of the output.
>> In any case it's not hard to
>> call a function in a class that writes the HTML before the content,
>> then write the content, then call another function that writes the
>> HTML after the content.
>
> Hmmm, yummy ! And SO maintainable...
>
Yes, why not?
>> This is how my sites are run, though in PHP
>> instead of Python. No prepackaged templates.
>
> PHP *is* a template language.
>
This is, in general what I'm doing:
<?php
// process GET POST and cookie variables, deal with mysql if needed
$title="blah";
include_once"/path/to/headerFile";
print "$content";
include_once"/path/to/footerFile";
exit();
?>
>> I would really like to know what else. So far, I am not convinced that
>> a framework offers anything that is not already easily accomplished in
>> Python.
>
> Given that we're talking about Python frameworks, it seems obvious that what
> they do can be accomplished in Python. Now the question is how much you like
> to write the same boring and error-prone boilerplate code project after
> project...
>
Like I said before, I don't want to have to maintain the functions
that turn the HTTP environment into Python variables, or the code that
manages database connections. Functions that escape data to be sent to
MySQL (to prevent sql injection) would be nice. Other than that, it's
all on me.
Dotan Cohen
>> looked at Django and other frameworks it seems that the web frameworks
>> push the coder to use templates, not letting him near the HTML.
>
> Well... there must be a reason, for sure... No ?
>
ֹYes, but I don't like it.
>> Django and the other frameworks seem to
>> force the user to use templates.
>
> Not at all. Nothing prevents you from shooting yourself in the foot and
> generating HTML "by hand" in your view functions (or request handler methods
> etc, depending on the framework).
How is this done in Django, then?
> This is just plain stupid wrt/
> readability, maintainability, reuse and whatnot, but hey, if you want to
> waste your time, please do. As far as i'm concerned, I'm very happy to let
> the HTML coder write the HTML part and the application programmer write the
> applicative part - even when I end up wearing both caps.
>
I've done stupider things.
>> 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,
>
> Why so ? Almost any programming language can do CGI.
And I settled on PHP because it does what I need. However, I would
prefer to move it to Python for the benefit of using the same language
in the different places that I code for (such as personal applications
for the desktop, pyqt).
Dotan Cohen
>> 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.
>
> $python
>>>help(cgi)
>>>help(cgitb)
>>>help(Cookie)
>>>help(urlparse)
>>>help(os.environ)
>
> GET variables:
> -------------------------------------------------------------------------
> import os,cgi
> if os.environ.has_key('QUERY_STRING'):
> getv = cgi.parse_qs(os.environ['QUERY_STRING'])
> print getv.keys()
>
> Other examples is very simple too...
>
Thanks, Mikhail. I now have a bit to google on.
Mikhail M.Smagin
On Wed, 28 Oct 2009 10:26:22 +0200
Dotan Cohen <dotan...@gmail.com> wrote:
> 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.
$python
>>help(cgi)
>>help(cgitb)
>>help(Cookie)
>>help(urlparse)
>>help(os.environ)
GET variables:
-------------------------------------------------------------------------
import os,cgi
if os.environ.has_key('QUERY_STRING'):
getv = cgi.parse_qs(os.environ['QUERY_STRING'])
print getv.keys()
Other examples is very simple too...
--
Mikhail M.Smagin <m...@x3.dp.ua>
Bruno Desthuilliers
> 2009/10/28 Bruno Desthuilliers <bruno.42.de...@websiteburo.invalid>:
>> Dotan Cohen a écrit :
>>>> declarative mapping of urls to code
>>> Apache does this, unless I am misunderstanding you.
>> Using url rewriting ? Yes, fine. Then tell me how you implement "reverse"
>> url generation (like Django or Routes do).
>
> I have no idea what reverse url generation is.
It's a mean to avoid hard-coding urls in your application code - the url
is fully generated by the 'url mapping' system.
> I assume that the user
> will call http://example.com/path/to/script.py?var1=hello&var2=world
>
> script.py would live in /home/user/site-name/public_html/path/to/
>
Now try to use apache url rewrites to use "nice urls" (like,
"/<section-name>/<sub-section-name>/<article-name>" instead of
"path/to/script-serving-articles.wtf?id=42"). Good luck.
>
>>>> of code to templates
>>> Those who code in HTML don't need this.
>> ???
>>
>
> I would prefer to output everything from <html> to </html> with print
> statements. I don't want some framework wrapping my output in tags, I
> want the tags to be part of the output.
You're confusing the framework and the templating system. The framework
by itself won't wrap your "output" in anything, nor even forces you to
"output" HTML. Also FWIW, it's HTTP, so we don't have "outputs", we have
HTTP responses.
>
>>> In any case it's not hard to
>>> call a function in a class that writes the HTML before the content,
>>> then write the content, then call another function that writes the
>>> HTML after the content.
>> Hmmm, yummy ! And SO maintainable...
>>
>
> Yes, why not?
Let's say I want to reuse your app with a different presentation. Do I
have to fork the whole application and send my HTML coder dig into your
applicative code just to rewrite the HTML parts ?
>
>>> This is how my sites are run, though in PHP
>>> instead of Python. No prepackaged templates.
>> PHP *is* a template language.
(snip)
>>> I would really like to know what else. So far, I am not convinced that
>>> a framework offers anything that is not already easily accomplished in
>>> Python.
>> Given that we're talking about Python frameworks, it seems obvious that what
>> they do can be accomplished in Python. Now the question is how much you like
>> to write the same boring and error-prone boilerplate code project after
>> project...
>>
>
> Like I said before, I don't want to have to maintain the functions
> that turn the HTTP environment into Python variables,
"HTTP environment" ???
Oh, you mean HTTP requests etc... Well, the cgi module already provides
some basic support here.
> or the code that
> manages database connections. Functions that escape data to be sent to
> MySQL (to prevent sql injection) would be nice.
Any DB-API compliant module already provide this - granted you use it
correctly.
> Other than that, it's
> all on me.
Your choice...
Bruno Desthuilliers
>>> 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.
>> Well... there must be a reason, for sure... No ?
>>
>
> ֹYes, but I don't like it.
Why so ? What's your problem with templating systems, exactly ?
>
>>> Django and the other frameworks seem to
>>> force the user to use templates.
>> Not at all. Nothing prevents you from shooting yourself in the foot and
>> generating HTML "by hand" in your view functions (or request handler methods
>> etc, depending on the framework).
>
> How is this done in Django, then?
def index(request):
unmaintanable_html = """
<html>
<head>
<title>Index</title>
</head>
<body>
<h1>Embedded HTML is a PITA</h1>
<p>but some like pains...</p>
</body>
</html>
"""
return HttpResponse(unmaintanable_html)
>
>> This is just plain stupid wrt/
>> readability, maintainability, reuse and whatnot, but hey, if you want to
>> waste your time, please do. As far as i'm concerned, I'm very happy to let
>> the HTML coder write the HTML part and the application programmer write the
>> applicative part - even when I end up wearing both caps.
>
> I've done stupider things.
Your choice, once again...
Bruno Desthuilliers
>>> 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.
>>
>
> I insist on handling the HTML myself.
I just don't get how embedding HTML in applicative code - a well-known
antipattern FWIW - relates to "handling the HTML yourself". Can you
*please* explain how a templating system prevents you from "handling the
HTML" yourself.
>> I think you underestimate the task it is to make a webapplication good.
>
> Probably, but that would not depend on the scripting language. I make
> bad webapplications in PHP too!
Lol !
>
>> And
>> even if not, what you will do is ... code your own webframework.
>
> That is why I am looking for a class that handles the backend stuff,
> but lets _me_ handle the HTML.
For God's sake : *why on earth do you believe that using a templating
system will make you loose _any_ control on the HTML code ???*
>> 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.
>>
>
> I am trying to follow you here. What is "return whatever you want"?
> Return HTML to stdout to be sent to the browser?
please leave stdout out of here - it's HTTP, so what we have are HTTP
requests and HTTP responses - not stdin nor stdout. Using these streams
as a mean of communication between the web server and the applicative
code is just plain old low-level GCI stuff. Your application code
shouldn't have any knowledge of this implementation detail - it should
receive (a suitable representation of) an HTTP request, and generate (a
suitable representation of) an HTTP response.
Diez B. Roggisch
>>> 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.
>>
>
> I insist on handling the HTML myself. As for converting the request
> variables into Python variables, if a class/framework makes that
> easier then I would gladly use it. My question was serious. How can I
> do those things?
Using a framework? In Pylons/TG2, my code looks like this:
def some_form_action(self, name, email, password):
....
so HTTP-variables get parsed, validated, converted, and *then* passed to my
actual code.
>> But then do you deal with headers correctly?
>
> Yes, so far as I know. This is actually simpler than the HTML, just be
> careful not to output two newline characters in sequence (thereby
> ending the header).
Oh my god. If two newlines are all you think that there is to properly
writing HTTP-headers, no wonder *you* wonder what to use a webframework
for.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.2
That's just an *overwiew* of what different kinds of headers there are, all
of which might require specific rules to parse or generate.
>
>> Do you respect character
>> encodings?
>
> Yes! UTF-8 from database to scripting language to HTTP request.
And if the browser sends them in different encoding? Frameworks make you
deals with unicode only. Decoding/Encoding, setting the necessary
>> Form-encodings?
>
> Yes, UTF-8 the in the other direction. However, as form data can be
> spoofed, I would like a function that checks it. Does Python have such
> a function? What class does?
Frameworks do check for HTTP-headers that contain the encoding, and thus
convert incoming data to unicode.
>
>
>> Is your generated HTML valid?
>
> Naturally, even though this is not a Python issue.
"Naturally" with print-statements?
I use genshi templating, which is XML-based, so I can't even write invalid
HTML for a great deal of cases.
>
>
>> Are
>> timestamp-formats generated according to RFCs for your cookies?
>
> Yes, this is not a problem. Is there some gothcha that I am unaware of?
The thing is that using a framework, I just pass a datetime-object. Others
have done it right for me translating that to the needed format.
>
>
>> Do you parse
>> content negotiation headers?
>>
>
> No. I hate sites that do that. If the page is available in another
> language, their is a link in the corner.
Again, you don't seem to really know much about webapps. Content-negotiation
isn't about languages, it's about content-types. Such as serving HTML or
JSON from the same URL. But let me guess, you hate applications that do
that?
>
>
>> I think you underestimate the task it is to make a webapplication good.
>
> Probably, but that would not depend on the scripting language. I make
> bad webapplications in PHP too!
I don't have the *slightest* doubt about that. In fact, I'm pretty sure you
can make pretty bad webapplications in pretty much everything you touch.
Good luck with that.
Diez
Dotan Cohen
>
> It's a mean to avoid hard-coding urls in your application code - the url is
> fully generated by the 'url mapping' system.
>
I don't need that, see below.
>> I assume that the user
>> will call http://example.com/path/to/script.py?var1=hello&var2=world
>>
>> script.py would live in /home/user/site-name/public_html/path/to/
>>
>
> Now try to use apache url rewrites to use "nice urls" (like,
> "/<section-name>/<sub-section-name>/<article-name>" instead of
> "path/to/script-serving-articles.wtf?id=42"). Good luck.
>
Actually, currently in the example url
http://example.com/path/to/script.py?var1=hello&var2=world the script
is /home/user/site-name/public_html/path/ (with no filename extension)
and the script.py is actually page.html which is an arbitrary,
descriptive string and not part of the script filename. See the pages
on http://dotancohen.com for examples.
>> I would prefer to output everything from <html> to </html> with print
>> statements. I don't want some framework wrapping my output in tags, I
>> want the tags to be part of the output.
>
> You're confusing the framework and the templating system. The framework by
> itself won't wrap your "output" in anything, nor even forces you to "output"
> HTML.
This is what I was hoping to hear. I don't remember the details, but I
had a hard time outputting the HTML myself in Django. I will play with
it again soon if I get the chance.
> Also FWIW, it's HTTP, so we don't have "outputs", we have HTTP
> responses.
>
Clearly. I was referring to stdout being send to the browser as the
http response. I think I mentioned that, but I apologize for being
unclear.
>> Yes, why not?
>
> Let's say I want to reuse your app with a different presentation. Do I have
> to fork the whole application and send my HTML coder dig into your
> applicative code just to rewrite the HTML parts ?
>
No, just replace two files. In that manner it is templating. Again, an
example from the current PHP code:
<?php
$variables_for_header="blah";
include "/path/to/header.inc";
// content here
include "/path/to/footer.inc";
?>
>> Like I said before, I don't want to have to maintain the functions
>> that turn the HTTP environment into Python variables,
>
> "HTTP environment" ???
>
> Oh, you mean HTTP requests etc... Well, the cgi module already provides some
> basic support here.
>
Does it? I will look into that. I assume that basic support means
making the cookie, GET and POST variables easily accessible. I google,
but cannot find any exapmles of this online.
>> or the code that
>> manages database connections. Functions that escape data to be sent to
>> MySQL (to prevent sql injection) would be nice.
>
> Any DB-API compliant module already provide this - granted you use it
> correctly.
>
I know. This is will use correctly, I promise!
>> Other than that, it's
>> all on me.
>
> Your choice...
>
Hey! Since when am I not under attack? :)
Dotan Cohen
>>>> looked at Django and other frameworks it seems that the web frameworks
>>>> push the coder to use templates, not letting him near the HTML.
>>>
>>> Well... there must be a reason, for sure... No ?
>>>
>>
>> ֹYes, but I don't like it.
>
> Why so ? What's your problem with templating systems, exactly ?
>
They don't give me the control over the HTML that I would like. I'm
probably stuck in 1998 when they didn't exist, but I like to write the
HTML myself.
>>>> Django and the other frameworks seem to
>>>> force the user to use templates.
>>>
>>> Not at all. Nothing prevents you from shooting yourself in the foot and
>>> generating HTML "by hand" in your view functions (or request handler
>>> methods
>>> etc, depending on the framework).
>>
>> How is this done in Django, then?
>
> def index(request):
> unmaintanable_html = """
> <html>
> <head>
> <title>Index</title>
> </head>
> <body>
> <h1>Embedded HTML is a PITA</h1>
> <p>but some like pains...</p>
> </body>
> </html>
> """
> return HttpResponse(unmaintanable_html)
>
And if I need to add a variable or three in there? Static HTML I can
do without Python.
Dotan Cohen
>
> I just don't get how embedding HTML in applicative code - a well-known
> antipattern FWIW - relates to "handling the HTML yourself". Can you *please*
> explain how a templating system prevents you from "handling the HTML"
> yourself.
>
>From the little that I played with Django, it looked like I would (for
the sake of argument I am just using the term output, but the
intention should be clear) output "Hello, world!" and Django would
mangle that into <html><body><p>Hello, world!</p></body></html>. It
did not look like I had any control over the tags at all.
>>> And
>>> even if not, what you will do is ... code your own webframework.
>>
>> That is why I am looking for a class that handles the backend stuff,
>> but lets _me_ handle the HTML.
>
> For God's sake : *why on earth do you believe that using a templating system
> will make you loose _any_ control on the HTML code ???*
>
Because that's what I've seen of them.
>>> 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.
>>>
>>
>> I am trying to follow you here. What is "return whatever you want"?
>> Return HTML to stdout to be sent to the browser?
>
> please leave stdout out of here - it's HTTP, so what we have are HTTP
> requests and HTTP responses - not stdin nor stdout. Using these streams as a
> mean of communication between the web server and the applicative code is
> just plain old low-level GCI stuff. Your application code shouldn't have any
> knowledge of this implementation detail - it should receive (a suitable
> representation of) an HTTP request, and generate (a suitable representation
> of) an HTTP response.
Can you provide a code example of printing the variable "torvalds" in
the GET request?
http://example.com/page.py?torvalds=tux
Should return this:
<html><body><p>tux</p></body></html>
And something similar for a POST request?
I hate to ask for code, but this conversation would be easier that way. Thanks.
Diez B. Roggisch
I've already given you that for TG:
class RootController(BaseController):
@expose()
def page(self, torwalds=None):
return "<html><body><p>%s</p></body></html>" % (torwalds if torwalds
else ""
Of course nobody would do it that way. Instead, you'd define a template
<html
xmlns:py='http://genshi.edgewall.org/'><body><p>${torvalds}</p></body></html>
And then your code becomes:
@expose("your.template.path")
def page(self, torwalds=None):
return dict(torwalds=torwalds)
Separation of code from HTML-code. Which most people agree is a good thing.
And no worries about having to make torwalds a string.
Now let's say you want torwalds to be not-empty, and a number:
@expose("your.template.path")
@validate(dict(torwalds=Int(not_empty=True)),
error_handler=some_error_handler_controller_action)
def page(self, torwalds=None):
return dict(torwalds=torwalds)
Diez
Dotan Cohen
>> variables into Python variables, if a class/framework makes that
>> easier then I would gladly use it. My question was serious. How can I
>> do those things?
>
> Using a framework? In Pylons/TG2, my code looks like this:
>
> def some_form_action(self, name, email, password):
>
> ....
>
> so HTTP-variables get parsed, validated, converted, and *then* passed to my
> actual code.
>
I know how to call a function, but how do I use the variables? How do
I respond (I am avoiding the term output) with the value of the GET
variable "torvalds", for example? And similarly for a POST variable?
>>> But then do you deal with headers correctly?
>>
>> Yes, so far as I know. This is actually simpler than the HTML, just be
>> careful not to output two newline characters in sequence (thereby
>> ending the header).
>
> Oh my god. If two newlines are all you think that there is to properly
> writing HTTP-headers, no wonder *you* wonder what to use a webframework
> for.
>
I was being brief. I don't pretend to know the whole protocol by
heart, but I get by that far. :)
>>> Do you respect character
>>> encodings?
>>
>> Yes! UTF-8 from database to scripting language to HTTP request.
>
> And if the browser sends them in different encoding? Frameworks make you
> deals with unicode only. Decoding/Encoding, setting the necessary
>
That's what I wrote below:
>>> Form-encodings?
>>
>> Yes, UTF-8 the in the other direction. However, as form data can be
>> spoofed, I would like a function that checks it. Does Python have such
>> a function? What class does?
>
> Frameworks do check for HTTP-headers that contain the encoding, and thus
> convert incoming data to unicode.
>
That is useful, thanks.
>>
>>
>>> Is your generated HTML valid?
>>
>> Naturally, even though this is not a Python issue.
>
> "Naturally" with print-statements?
>
"Carefully" with print statements.
>>> Do you parse
>>> content negotiation headers?
>>>
>>
>> No. I hate sites that do that. If the page is available in another
>> language, their is a link in the corner.
>
> Again, you don't seem to really know much about webapps. Content-negotiation
> isn't about languages, it's about content-types. Such as serving HTML or
> JSON from the same URL. But let me guess, you hate applications that do
> that?
>
I used to serve WML-specific "decks" to known mobile UA's, but I've stopped.
> I don't have the *slightest* doubt about that. In fact, I'm pretty sure you
> can make pretty bad webapplications in pretty much everything you touch.
> Good luck with that.
>
I am a mechanical engineering student, not CS. I am doing this for my
own use and enjoyment. I don't need luck with that, I don't have any
customers. If someone were to come along asking me to code for them, I
would send them to you!
Bruno Desthuilliers
>>> I have no idea what reverse url generation is.
>> It's a mean to avoid hard-coding urls in your application code - the url is
>> fully generated by the 'url mapping' system.
>>
>
> I don't need that, see below.
>
>
>>> I assume that the user
>>> will call http://example.com/path/to/script.py?var1=hello&var2=world
>>>
>>> script.py would live in /home/user/site-name/public_html/path/to/
>>>
>> Now try to use apache url rewrites to use "nice urls" (like,
>> "/<section-name>/<sub-section-name>/<article-name>" instead of
>> "path/to/script-serving-articles.wtf?id=42"). Good luck.
>>
>
> Actually, currently in the example url
> http://example.com/path/to/script.py?var1=hello&var2=world the script
> is /home/user/site-name/public_html/path/ (with no filename extension)
> and the script.py is actually page.html which is an arbitrary,
> descriptive string and not part of the script filename.
Better than the first example wrt/ SEO, but this still ties your "url
space" to implementation AFAICT.
>
>>> I would prefer to output everything from <html> to </html> with print
>>> statements. I don't want some framework wrapping my output in tags, I
>>> want the tags to be part of the output.
>> You're confusing the framework and the templating system. The framework by
>> itself won't wrap your "output" in anything, nor even forces you to "output"
>> HTML.
>
> This is what I was hoping to hear. I don't remember the details, but I
> had a hard time outputting the HTML myself in Django. I will play with
> it again soon if I get the chance.
>
>
>> Also FWIW, it's HTTP, so we don't have "outputs", we have HTTP
>> responses.
>>
>
> Clearly. I was referring to stdout being send to the browser as the
> http response.
s/browser/web server/ - it's the web server that reads your app's stdout
and send it (as is or not FWIW) back to the client. And this "output to
stdout" thingie is just the ipc scheme used for CGI - there are other
possible interfaces between the application code and the web server.
> I think I mentioned that, but I apologize for being
> unclear.
It's not that it was unclear, but that it's innaccurate. "outputting to
stdout" is an implementation detail, and should not be exposed at the
applicative code level. Dealing with appropriate abstraction - here, an
HttpResponse object - is far better (well, IMHO of course... - standard
disclaimers, YMMV etc).
>>> Yes, why not?
>> Let's say I want to reuse your app with a different presentation. Do I have
>> to fork the whole application and send my HTML coder dig into your
>> applicative code just to rewrite the HTML parts ?
>>
>
> No, just replace two files. In that manner it is templating. Again, an
> example from the current PHP code:
>
> <?php
> $variables_for_header="blah";
> include "/path/to/header.inc";
>
> // content here
>
> include "/path/to/footer.inc";
> ?>
Sorry, but all I can "replace" here are the header and footer - if I
want to generate a different markup for the "content here" part, I have
to modify your applicative code. I've written web apps that way myself
(some 7 years ago), and still have to maintain some web apps written
that way, you know...
>
>>> Like I said before, I don't want to have to maintain the functions
>>> that turn the HTTP environment into Python variables,
>> "HTTP environment" ???
>>
>> Oh, you mean HTTP requests etc... Well, the cgi module already provides some
>> basic support here.
>>
>
> Does it? I will look into that. I assume that basic support means
> making the cookie, GET and POST variables easily accessible.
GET and POST at least - I don't exactly remember how it works for cookies.
> I google,
> but cannot find any exapmles of this online.
Well, no one in it's own mind would still use CGI (except perhaps for
very trivial stuff) when you have way better solutions.
>
>>> or the code that
>>> manages database connections. Functions that escape data to be sent to
>>> MySQL (to prevent sql injection) would be nice.
>> Any DB-API compliant module already provide this - granted you use it
>> correctly.
>>
>
> I know. This is will use correctly, I promise!
>
>
>>> Other than that, it's
>>> all on me.
>> Your choice...
>>
>
> Hey! Since when am I not under attack? :)
Mmm... yes, I tend to be a bit offensive sometimes - please don't take
it personnaly and forgive me for my lack of social skills. What I
express are of course _my_ opinions (most of them based on experience
but that's not the point), and I've never killed anyone for having a
different POV - even if I'm pretty sure they are wrong !-)
Bruno Desthuilliers
>>>>> 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.
>>>> Well... there must be a reason, for sure... No ?
>>>>
>>> ֹYes, but I don't like it.
>> Why so ? What's your problem with templating systems, exactly ?
>>
>
> They don't give me the control over the HTML that I would like. I'm
> probably stuck in 1998 when they didn't exist, but I like to write the
> HTML myself.
<once-again>
*Why* on earth do you think using a templating system will give you any
less control on the generated HTML ?
</once-again>
>
>>>>> Django and the other frameworks seem to
>>>>> force the user to use templates.
>>>> Not at all. Nothing prevents you from shooting yourself in the foot and
>>>> generating HTML "by hand" in your view functions (or request handler
>>>> methods
>>>> etc, depending on the framework).
>>> How is this done in Django, then?
>> def index(request):
>> unmaintanable_html = """
>> <html>
>> <head>
>> <title>Index</title>
>> </head>
>> <body>
>> <h1>Embedded HTML is a PITA</h1>
>> <p>but some like pains...</p>
>> </body>
>> </html>
>> """
>> return HttpResponse(unmaintanable_html)
>>
>
> And if I need to add a variable or three in there?
- first solution : use string formatting
python 2.x example:
unmaintanable_html = """
<html>
<head>
<title>%(title)s</title>
</head>
<body>
<h1>%(h1)s</h1>
<p>%(text)s</p>
</body>
</html>
"""
data = dict(
title="index",
h1="Poor man's templating",
text="Won't get you very far..."
)
return HttpResponse(unmaintanable_html % data)
- second solution: do basically the same thing with a template system -
which will give you much more power and options...
> Static HTML I can
> do without Python.
Sorry, I forgot to setup a database etc for this example !-)
Dotan Cohen
> control on the generated HTML ?
>
Because I am wrong. I have already come to that conclusion.
I know that Python is far enough developed that if I feel that I am
fighting it, then _I_ am in the wrong, not Python. However, I still
need to see that Python can do what I need in a comfortable fashion.
>> And if I need to add a variable or three in there?
>
> - first solution : use string formatting
>
> python 2.x example:
>
> unmaintanable_html = """
> <html>
> <head>
> <title>%(title)s</title>
> </head>
> <body>
> <h1>%(h1)s</h1>
> <p>%(text)s</p>
> </body>
> </html>
> """
>
> data = dict(
> title="index",
> h1="Poor man's templating",
> text="Won't get you very far..."
> )
>
> return HttpResponse(unmaintanable_html % data)
>
That's fine for single variables, but if I need to output a table of
unknown rows? I assume that return means the end of the script.
Therefore I should shove the whole table into a variable and then copy
that variable to the array "data"?
> - second solution: do basically the same thing with a template system -
> which will give you much more power and options...
>
I will look further into the Django templates, I promise. But I would
still like to know how to work with Python proper.
>> Static HTML I can
>> do without Python.
>
> Sorry, I forgot to setup a database etc for this example !-)
>
I meant that I would like to see how to output variables, which you have shown.
Thanks. I am stubborn, but I am willing to learn.
Bruno Desthuilliers
>>> I insist on handling the HTML myself.
>> I just don't get how embedding HTML in applicative code - a well-known
>> antipattern FWIW - relates to "handling the HTML yourself". Can you
*please*
>> explain how a templating system prevents you from "handling the HTML"
>> yourself.
>>
>
>>From the little that I played with Django, it looked like I would (for
> the sake of argument I am just using the term output, but the
> intention should be clear) output "Hello, world!" and Django would
> mangle that into <html><body><p>Hello, world!</p></body></html>.
I don't know how you got that result - but it's certainly *not* what I
get here.
> It
> did not look like I had any control over the tags at all.
I can tell you you have full control over the whole HTTP response's
content and headers. And FWIW, this has nothing to do with templating
systems.
>
>>>> And
>>>> even if not, what you will do is ... code your own webframework.
>>> That is why I am looking for a class that handles the backend stuff,
>>> but lets _me_ handle the HTML.
>> For God's sake : *why on earth do you believe that using a
templating system
>> will make you loose _any_ control on the HTML code ???*
>>
>
> Because that's what I've seen of them.
I use Django's templates to generate any kind of textual content - not
only HTML. I could even use them to generate Python source code. And
that's true for quite a few other templating systems around (Mako,
Jinja, Cheetah, just to name a few).
>
>>>> 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.
>>>>
>>> I am trying to follow you here. What is "return whatever you want"?
>>> Return HTML to stdout to be sent to the browser?
>
>> please leave stdout out of here - it's HTTP, so what we have are HTTP
>> requests and HTTP responses - not stdin nor stdout. Using these
streams as a
>> mean of communication between the web server and the applicative code is
>> just plain old low-level GCI stuff. Your application code shouldn't
have any
>> knowledge of this implementation detail - it should receive (a suitable
>> representation of) an HTTP request, and generate (a suitable
representation
>> of) an HTTP response.
>
> Can you provide a code example of printing the variable "torvalds" in
> the GET request?
> http://example.com/page.py?torvalds=tux
> Should return this:
> <html><body><p>tux</p></body></html>
>
> And something similar for a POST request?
Using which framework ? If it's about Turbogears, I don't use it so I
can't answer. If it's using Pylons, you can use almost whatever
templating system you want - or not use any. If it's with Django, do you
want it with or without the templating system ?
> I hate to ask for code, but this conversation would be easier that way.
Mmmm.... May I suggest that you first read the relevant documentation
for the aforementionned frameworks ?
Ok, here's a Django example without a template:
# views.py
def index(request):
torvalds = request.GET.get("torvalds", "No torvalds here")
return HttpResponse("<html><body>%s</body></html>" % torvalds)
and here's an exemple using a template:
# templates/index.html
<html>
<body>
{{ torvalds }}
</body>
</html
# views.py
def index(request):
torvalds = request.GET.get("torvalds", "No torvalds here")
return render_to_response("index.html", dict(torvalds=torvalds))
Bruno Desthuilliers
What do you think templates are for ?
> I assume that return means the end of the script.
It means that this function returns an HttpResponse object.
> Therefore I should shove the whole table into a variable and then copy
> that variable to the array "data"?
If you really love feeling the pain, that's a possible solution. I for
one would rather use a template... But once again, your choice !-)
>
>> - second solution: do basically the same thing with a template system -
>> which will give you much more power and options...
>>
>
> I will look further into the Django templates, I promise. But I would
> still like to know how to work with Python proper.
Using the appropriate tool for the job is "proper Python". The
appropriate tool for generating formatted text with static and dynamic
parts is a template system. Good news, there are quite a few available
in Python.
John Nagle
The main web site for MySQLdb says it is only supported through Python 2.5.
"http://sourceforge.net/projects/mysql-python/"
"MySQL support for Python. MySQL versions 3.23-5.1; and Python versions 2.3-2.5
are supported."
There does seem to be a 2.6 download for Linux, but the SourceForge download
for Windows is for Python 2.5. Maybe the 2.6 version, with a "c1" suffix,
is an unsupported release candidate.
John Nagle
Dotan Cohen
>> did not look like I had any control over the tags at all.
>
> I can tell you you have full control over the whole HTTP response's content
> and headers. And FWIW, this has nothing to do with templating systems.
>
That's good to know. Actually, it's more that good: I am looking into
Django again.
>> Can you provide a code example of printing the variable "torvalds" in
>> the GET request?
>> http://example.com/page.py?torvalds=tux
>> Should return this:
>> <html><body><p>tux</p></body></html>
>>
>> And something similar for a POST request?
>
>
> Using which framework ? If it's about Turbogears, I don't use it so I can't
> answer. If it's using Pylons, you can use almost whatever templating system
> you want - or not use any. If it's with Django, do you want it with or
> without the templating system ?
>
I'd love to see the non-templating Pylons example, and/or the Django
example. Better yet, a link to example code or the appropriate chapter
of TFM would be welcome. So far as I can tell, the fine manual does
not cover non-template output.
>> I hate to ask for code, but this conversation would be easier that way.
>
> Mmmm.... May I suggest that you first read the relevant documentation for
> the aforementionned frameworks ?
>
Yes, please! Where in the Django docs is the relevant chapter?
> Ok, here's a Django example without a template:
>
> # views.py
> def index(request):
> torvalds = request.GET.get("torvalds", "No torvalds here")
> return HttpResponse("<html><body>%s</body></html>" % torvalds)
>
>
Allright, but what if I need to output in the middle of the page? Say,
one row of a table that is neither the end nor beginning of the code?
I ask because the construct "return" makes me believe that this is not
good for this purpose.
> and here's an exemple using a template:
>
> # templates/index.html
>
> <html>
> <body>
> {{ torvalds }}
> </body>
> </html
>
>
> # views.py
> def index(request):
> torvalds = request.GET.get("torvalds", "No torvalds here")
> return render_to_response("index.html", dict(torvalds=torvalds))
>
Again, how could I output something in the middle of the page with the
templates?
Dotan Cohen
>
> class RootController(BaseController):
>
> @expose()
> def page(self, torwalds=None):
> return "<html><body><p>%s</p></body></html>" % (torwalds if torwalds
> else ""
>
Does return mean that this could not be used in the middle of a page?
> Of course nobody would do it that way. Instead, you'd define a template
>
> <html
> xmlns:py='http://genshi.edgewall.org/'><body><p>${torvalds}</p></body></html>
>
>
> And then your code becomes:
>
>
>
> @expose("your.template.path")
> def page(self, torwalds=None):
> return dict(torwalds=torwalds)
>
>
> Separation of code from HTML-code. Which most people agree is a good thing.
> And no worries about having to make torwalds a string.
>
Yes, I like to separate HTML from code. However, often I need to
output something in the middle of the page. How could I do that with a
template?
> Now let's say you want torwalds to be not-empty, and a number:
>
> @expose("your.template.path")
> @validate(dict(torwalds=Int(not_empty=True)),
> error_handler=some_error_handler_controller_action)
> def page(self, torwalds=None):
> return dict(torwalds=torwalds)
>
That is nice, I will read more about the error_handler functions. Thanks.
Dotan Cohen
>> http://example.com/path/to/script.py?var1=hello&var2=world the script
>> is /home/user/site-name/public_html/path/ (with no filename extension)
>> and the script.py is actually page.html which is an arbitrary,
>> descriptive string and not part of the script filename.
>
> Better than the first example wrt/ SEO, but this still ties your "url space"
> to implementation AFAICT.
>
Yes, but for the purposes of my needs this is fine and preferable. SEO
was in fact the reason that I started doing this.
>> Clearly. I was referring to stdout being send to the browser as the
>> http response.
>
> s/browser/web server/ - it's the web server that reads your app's stdout and
> send it (as is or not FWIW) back to the client.
As is, in my case. Actually, what use case is there for having Apache
reprocess the HTML output of the script?
> And this "output to stdout"
> thingie is just the ipc scheme used for CGI - there are other possible
> interfaces between the application code and the web server.
>
Other possible interfaces between the application code and the web
server? Maybe you are referring to the interface with the database
server? Enlighten me, please! I am not a programmer by trade, only by
hobby.
>> I think I mentioned that, but I apologize for being
>> unclear.
>
> It's not that it was unclear, but that it's innaccurate. "outputting to
> stdout" is an implementation detail, and should not be exposed at the
> applicative code level. Dealing with appropriate abstraction - here, an
> HttpResponse object - is far better (well, IMHO of course... - standard
> disclaimers, YMMV etc).
>
I see. I believe that is called Dotan's Razor: a slight inaccuracy
saves a lengthy explanation.
> Sorry, but all I can "replace" here are the header and footer - if I want to
> generate a different markup for the "content here" part, I have to modify
> your applicative code. I've written web apps that way myself (some 7 years
> ago), and still have to maintain some web apps written that way, you know...
>
Quite so, I though that is what you wanted. Yes, the HTML is
hard-coded into the script. I am learning to abstract and even use
object-oriented approaches, though.
>> Does it? I will look into that. I assume that basic support means
>> making the cookie, GET and POST variables easily accessible.
>
> GET and POST at least - I don't exactly remember how it works for cookies.
>
That much I should be able to google when I get to it.
>> I google,
>> but cannot find any exapmles of this online.
>
> Well, no one in it's own mind would still use CGI (except perhaps for very
> trivial stuff) when you have way better solutions.
>
What I am doing _is_ trivial. However, I thank you for explaining my
options and I will take a second look at them.
>> Hey! Since when am I not under attack? :)
>
> Mmm... yes, I tend to be a bit offensive sometimes - please don't take it
> personnaly and forgive me for my lack of social skills. What I express are
> of course _my_ opinions (most of them based on experience but that's not the
> point), and I've never killed anyone for having a different POV - even if
> I'm pretty sure they are wrong !-)
>
Be offensive! I take no offence, I understand that your goal is to
help me. I am a hard learner: I recognize that you are teaching me the
better way, but I need convincing as to why it is better. "Bruno said
so" is good, but "saves you coding time down the line" is a lot more
convincing!
Rami Chowdhury
wrote:
>> I've already given you that for TG:
>>
>> class RootController(BaseController):
>>
>> @expose()
>> def page(self, torwalds=None):
>> return "<html><body><p>%s</p></body></html>" % (torwalds if
>> torwalds
>> else ""
>>
>
> Does return mean that this could not be used in the middle of a page?
>
[snip]
> Yes, I like to separate HTML from code. However, often I need to
> output something in the middle of the page. How could I do that with a
> template?
>
What do you mean by "in the middle of the page"? Do you mean, for
instance, the behavior of "middle.php" in the following PHP example:
<?php
include_once("beginning.inc.php");
include_once("middle.php");
include_once("end.inc.php");
?>
Is that what you are after?
--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
Dotan Cohen
> the behavior of "middle.php" in the following PHP example:
>
> <?php
>
> include_once("beginning.inc.php");
>
> include_once("middle.php");
>
> include_once("end.inc.php");
>
> ?>
>
> Is that what you are after?
>
Yes, that is what I am after. For instance, if one were to look at the
source code of http://dotancohen.com they would see "<!-- / HEADER
-->". All the HTML up to that point was output by bigginin.inc.php.
Similarly, near the end exists "<div class="bottomfiller">", all the
code from there is generated by end.inc.php. These two files are
included in every page of the site.
Albert Hopkins
> > def index(request):
> > unmaintanable_html = """
> > <html>
> > <head>
> > <title>Index</title>
> > </head>
> > <body>
> > <h1>Embedded HTML is a PITA</h1>
> > <p>but some like pains...</p>
> > </body>
> > </html>
> > """
> > return HttpResponse(unmaintanable_html)
> >
>
> do without Python.
>
Put the variables in a dict and then return
unmaintanable_html % varDict
Or, if you want the the static HTML in a file then you can return
open(static_html_filename).read() % varDict
Add any complexity beyond that though and you're pretty much on your way
to writing a template engine ;-)
-a
Rami Chowdhury
wrote:
>> What do you mean by "in the middle of the page"? Do you mean, for
I think you're misunderstanding how Python and the web work together.
Python is not PHP -- it was not designed to replace HTML, and it is in
itself not a templating language. If you would like to use Python code
embedded in HTML, the way PHP is typically used, you may want to look at
Python Server Pages
(http://www.modpython.org/live/current/doc-html/pyapi-psp.html) which are
provided by mod_python.
Just so you know (as I think this is what is causing much of the
misunderstanding here), most Python web frameworks *do not* subscribe to
the traditional model of the web, where URLs represent files on a server.
(In the case of PHP, Python Server Pages, or CGI scripts, these are
augmented files which are executed by the server, but it's the same
concept). Instead, they typically map URLs to arbitrary code.
Albert Hopkins
> > return HttpResponse(unmaintanable_html % data)
> >
>
> That's fine for single variables, but if I need to output a table of
> Therefore I should shove the whole table into a variable and then copy
> that variable to the array "data"?
>
a QuerySet to your template. A QuerySet is basically a pointer to a SQL
query, for example. The templating system just knows to expect an
iterable, it can be a list of rows or it can be a QuerySet which does a
fetch from a database. No need to shove an entire table into a
variable.
>
> > - second solution: do basically the same thing with a template
> system -
> > which will give you much more power and options...
> >
>
> still like to know how to work with Python proper.
Another advantage if templates for many is that it allows programmers to
do what they do best (write code) while letting web designers do what
they do best (designing web pages) without them walking over each other
(that much).
Rhodri James
> Alan Harris-Reid wrote:
>> I am very much new to Python, and one of my first projects is a simple
>> data-based website. I am starting with Python 3.1
>
> Until MySQLdb gets ported to something later than Python 2.5, support
> for a "data-based web site" probably has to be in Python 2.5 or earlier.
Aside from the deprecation warning, MySQLdb appears to work perfectly well
on my Ubuntu Python 2.6. Since my spare-time teach-myself activity has
been
playing with it, I'd have expected to notice lack of support by now.
--
Rhodri James *-* Wildebeest Herder to the Masses
Alan Harris-Reid
> <div class="moz-text-flowed">Alan Harris-Reid wrote:
>> I am very much new to Python, and one of my first projects is a simple
>> data-based website. I am starting with Python 3.1
>
> Until MySQLdb gets ported to something later than Python 2.5, support
> for a "data-based web site" probably has to be in Python 2.5 or earlier.
>
> Realistically, the production version of Python is 2.5. This process
> is taking long enough that I'm worried that Python 3.x could do for
> Python what Perl 6 did for Perl - provide an upgrade path that nobody
> takes.
>
> HTMLTemplate
> ("http://py-templates.sourceforge.net/htmltemplate/index.html")
> is a minimal templating system for fill-in-the-blanks template work in
> Python.
> Actually, if you have HTMLTemplate, FCGI, and MySQLdb, you have enough to
> do a back-end database.
>
> There are some advantages to libraries (you call them) over
> "frameworks"
> (they call you) if you're doing something unusual. Frameworks are more
> useful if you're doing yet another "Web 2.0" web site.
>
> John Nagle
>
> </div>
>
Thanks for the advice John. I am concerned at what you say about the
uptake of 3.x - you could be right (although I hope you eventually
turn-out to be wrong :-) ).
Regards
Alan
Dotan Cohen
> is not PHP -- it was not designed to replace HTML, and it is in itself not a
> templating language. If you would like to use Python code embedded in HTML,
> the way PHP is typically used, you may want to look at Python Server Pages
> (http://www.modpython.org/live/current/doc-html/pyapi-psp.html) which are
> provided by mod_python.
>
I see, thank you! This is what has been bothering and confusing me. I
started with HTML and added PHP later, and the PHP fit in nicely
embedded in the HTML, and even though it's now HTML embedded in PHP
the principals are the same. Python doesn't seem to work that way, and
I have been having a hard time wrapping my head around just why.
> Just so you know (as I think this is what is causing much of the
> misunderstanding here), most Python web frameworks *do not* subscribe to the
> traditional model of the web, where URLs represent files on a server. (In
> the case of PHP, Python Server Pages, or CGI scripts, these are augmented
> files which are executed by the server, but it's the same concept). Instead,
> they typically map URLs to arbitrary code.
>
I don't think that I like that idea. I will give it a fair chance,
though, now that it problem has been identified.
Thank you very much for helping me understand this important distinction.
Dotan Cohen
> On Wed, 2009-10-28 at 16:38 +0200, Dotan Cohen wrote:
>> > return HttpResponse(unmaintanable_html % data)
>> >
>>
>> That's fine for single variables, but if I need to output a table of
>> unknown rows? I assume that return means the end of the script.
>> Therefore I should shove the whole table into a variable and then copy
>> that variable to the array "data"?
>>
> No, if you use a templating system like Django's then basically you pass
> a QuerySet to your template. A QuerySet is basically a pointer to a SQL
> query, for example. The templating system just knows to expect an
> iterable, it can be a list of rows or it can be a QuerySet which does a
> fetch from a database. No need to shove an entire table into a
> variable.
Sounds like the system is trying to outsmart the programmer here.
> Another advantage if templates for many is that it allows programmers to
> do what they do best (write code) while letting web designers do what
> they do best (designing web pages) without them walking over each other
> (that much).
>
I do see that advantage.
Bruno Desthuilliers
>
>>> Clearly. I was referring to stdout being send to the browser as the
>>> http response.
>> s/browser/web server/ - it's the web server that reads your app's stdout and
>> send it (as is or not FWIW) back to the client.
>
> As is, in my case. Actually, what use case is there for having Apache
> reprocess the HTML output of the script?
compression, cache, whatever...
>
>> And this "output to stdout"
>> thingie is just the ipc scheme used for CGI - there are other possible
>> interfaces between the application code and the web server.
>>
>
> Other possible interfaces between the application code and the web
> server?
Depends on the web server, obviously. With Apache you have things like
mod_python, mod_wsgi, or mod_php if you go that route.
FWIW, while I would not necessarily advise using mod_python (unless of
course you really need deep Apache integration instead of independance
from the frontal web server), reading the mod_python's manual might
teach you a lot about the processing of a HTTP request and what you can
do...
>
>>> I think I mentioned that, but I apologize for being
>>> unclear.
>> It's not that it was unclear, but that it's innaccurate. "outputting to
>> stdout" is an implementation detail, and should not be exposed at the
>> applicative code level. Dealing with appropriate abstraction - here, an
>> HttpResponse object - is far better (well, IMHO of course... - standard
>> disclaimers, YMMV etc).
>>
>
> I see. I believe that is called Dotan's Razor: a slight inaccuracy
> saves a lengthy explanation.
but also impacts your "mental map" of what's going on... You're thinking
in terms of streams and stdout, which, while not that far from actual
implementation (in the end it always boils down to bits sent over the
wires...), might not be the right level of abstraction when it comes to
application programming.
>
>> Sorry, but all I can "replace" here are the header and footer - if I want to
>> generate a different markup for the "content here" part, I have to modify
>> your applicative code. I've written web apps that way myself (some 7 years
>> ago), and still have to maintain some web apps written that way, you know...
>>
>
> Quite so, I though that is what you wanted. Yes, the HTML is
> hard-coded into the script. I am learning to abstract and even use
> object-oriented approaches, though.
You can have efficient abstraction and decoupling without resorting to
OO. Also, remember that PHP is first a templating language...
>>> I google,
>>> but cannot find any exapmles of this online.
>> Well, no one in it's own mind would still use CGI (except perhaps for very
>> trivial stuff) when you have way better solutions.
>
> What I am doing _is_ trivial.
What I saw is already complex enough to justify using better tools IMHO.
Or to make better use of the one you have.
> I understand that your goal is to
> help me. I am a hard learner: I recognize that you are teaching me the
> better way, but I need convincing as to why it is better. "Bruno said
> so" is good,
It isn't.
> but "saves you coding time down the line" is a lot more
> convincing!
Well, my POV is obviously biased - I've been doing mostly web
programming for 6 or 7 years now, and not as a hobby. When you have
several new projects to ship within a short timeline while still
maintaining older projects, you really start thinking hard about
readability, maintainability, and possible reuse. But wrt/ hard-coded
embedded HTML vs templating (even in it's simpler form), it's not a
matter of "bruno said so" - it's a well-known antipattern.
Bruno Desthuilliers
(snip)
>
> Yes, I like to separate HTML from code. However, often I need to
> output something in the middle of the page. How could I do that with a
> template?
Perhaps learning to use some templating system could help ?-)
I'd personnaly suggest either Mako (possibly one of the best Python
templating systems) or Django's (well documented and beginner-friendly).
Dotan Cohen
>> reprocess the HTML output of the script?
>
> compression, cache, whatever...
>
Thanks. I actually did think of compression.
>>> It's not that it was unclear, but that it's innaccurate. "outputting to
>>> stdout" is an implementation detail, and should not be exposed at the
>>> applicative code level. Dealing with appropriate abstraction - here, an
>>> HttpResponse object - is far better (well, IMHO of course... - standard
>>> disclaimers, YMMV etc).
>>>
>>
>> I see. I believe that is called Dotan's Razor: a slight inaccuracy
>> saves a lengthy explanation.
>
> but also impacts your "mental map" of what's going on... You're thinking in
> terms of streams and stdout, which, while not that far from actual
> implementation (in the end it always boils down to bits sent over the
> wires...), might not be the right level of abstraction when it comes to
> application programming.
>
Seeing how the templating engines work, I now know why my choice of
words bothered you. In fact, I was thinking in terms of PHP's linear
progress through the code which is not quite valid here. Thank you for
taking the time to set me straight.
> What I saw is already complex enough to justify using better tools IMHO. Or
> to make better use of the one you have.
>
I am beginning to see how true that is.
> I'd personnaly suggest either Mako (possibly one of the best Python
> templating systems) or Django's (well documented and beginner-friendly).
>
I will examine them both this weekend. Thanks!
Bruno Desthuilliers
>> What do you mean by "in the middle of the page"? Do you mean, for instance,
>> the behavior of "middle.php" in the following PHP example:
>>
>> <?php
>>
>> include_once("beginning.inc.php");
>>
>> include_once("middle.php");
>>
>> include_once("end.inc.php");
>>
>> ?>
>>
>> Is that what you are after?
>>
>
> Yes, that is what I am after.
Django's templating system has an "include" statement, but also
something you don't have in PHP : an "extends" statement. Yes, template
inheritance. This means that you can define the general basic layout for
all your site in one "base" template, and make your other templates just
fill the "blanks" you defined in the base template.
FWIW, I'm using Django has an example but quite a few other templating
systems have this "template inheritance" feature one way or another...
> For instance, if one were to look at the
> source code of http://dotancohen.com they would see "<!-- / HEADER
> -->". All the HTML up to that point was output by bigginin.inc.php.
> Similarly, near the end exists "<div class="bottomfiller">", all the
> code from there is generated by end.inc.php. These two files are
> included in every page of the site.
And ? Do you really thing we'd all be wasting time using templating
systems too dumb to do even such a simple thing ???
Perhaps this might better answer your questions:
http://docs.djangoproject.com/en/dev/topics/templates/#id1
Dotan Cohen
> http://docs.djangoproject.com/en/dev/topics/templates/#id1
>
Actually, that example just proves my point! Look at this "templating code":
{% for entry in blog_entries %}
<h2>{{ entry.title }}</h2>
<p>{{ entry.body }}</p>
{% endfor %}
Why would I want to learn that when Python already has a real for
loop? I know HTML, and I have a goal of learning Python for it's
reusability (desktop apps, for instance). I don't want to learn some
"templating language" that duplicates what Python already has built
in!
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.
Bruno Desthuilliers
>
>> Ok, here's a Django example without a template:
>>
>> # views.py
>> def index(request):
>> torvalds = request.GET.get("torvalds", "No torvalds here")
>> return HttpResponse("<html><body>%s</body></html>" % torvalds)
>>
>>
>
> Allright, but what if I need to output in the middle of the page? Say,
> one row of a table that is neither the end nor beginning of the code?
> I ask because the construct "return" makes me believe that this is not
> good for this purpose.
A django "view" function returns a full HttpResponse. It's nothing like
PHP's "server page" scheme - here you first build your full response,
then pass it back to the framework (which will deal with the frontal
webserver).
>
>> and here's an exemple using a template:
(snip)
> Again, how could I output something in the middle of the page with the
> templates?
Already answered elsewhere in this post.
Bruno Desthuilliers
> 2009/10/29 Albert Hopkins <mar...@letterboxes.org>:
>> On Wed, 2009-10-28 at 16:38 +0200, Dotan Cohen wrote:
>>>> return HttpResponse(unmaintanable_html % data)
>>>>
>>> That's fine for single variables, but if I need to output a table of
>>> unknown rows? I assume that return means the end of the script.
>>> Therefore I should shove the whole table into a variable and then copy
>>> that variable to the array "data"?
>>>
>> No, if you use a templating system like Django's then basically you pass
>> a QuerySet to your template. A QuerySet is basically a pointer to a SQL
>> query, for example. The templating system just knows to expect an
>> iterable, it can be a list of rows or it can be a QuerySet which does a
>> fetch from a database. No need to shove an entire table into a
>> variable.
>
> Sounds like the system is trying to outsmart the programmer here.
Why so ???
Bruno Desthuilliers
>> Perhaps this might better answer your questions:
>> http://docs.djangoproject.com/en/dev/topics/templates/#id1
>>
>
> Actually, that example just proves my point!
Which one ?
> 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.
> 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 !-)
> 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. 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 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 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.
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 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...
My 2 cents...
Ethan Furman
> Dotan Cohen a �crit :
>
>> 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...).
Good to know about Mako -- I don't want to have to learn yet another
language, either. Not, at least, until I have achieved Python Mastery!
:) Guess I better find some time to read through my Pylons book...
~Ethan~
Diez B. Roggisch
>> Perhaps this might better answer your questions:
>> http://docs.djangoproject.com/en/dev/topics/templates/#id1
>>
>
> Actually, that example just proves my point! Look at this "templating
> code":
> {% for entry in blog_entries %}
> <h2>{{ entry.title }}</h2>
> <p>{{ entry.body }}</p>
> {% endfor %}
>
> Why would I want to learn that when Python already has a real for
> loop? I know HTML, and I have a goal of learning Python for it's
> reusability (desktop apps, for instance). I don't want to learn some
> "templating language" that duplicates what Python already has built
> in!
The point is that using templates allows you to express your rendering-logic
in terms of the desired output language (HTML in this case).
This becomes even more apparent in genshi/KID, which use XML-namespaces
inside normal XHTML-documents to express their logic. And thus you can
- use a decent XML/HTML-editor to work with them, syntax-hilighting and
everthing included.
- communicate better with people who are only used to work with HTML
- aren't a slave to Python's whitespace rules which are fine for Python,
but not for HTML.
- validate the HTML and be sure you don't f*ck it up with forgotten
print-statements
And the overall separation of rendering from programming is a *great* thing
for maintainability.
Diez
Bruno Desthuilliers
>
> The point is that using templates allows you to express your rendering-logic
> in terms of the desired output language (HTML in this case).
Well, for Django, Mako, Cheetah and quite a few others, this might not
be _that_ true - you can use any of the templating systems to generate
almost any kind of text, not just HTML, and the templating logic itself
is _not_ expressed "in terms of the desired output language" (ie: the
"template langage" elements are not valid HTML).
> And the overall separation of rendering from programming is a *great* thing
> for maintainability.
+1 on this - even if some may argue that this shouldn't prevent you from
using Python to handle the presentation logic (whitespace problems set
aside, and cf Mako and Cheetah).
Dotan Cohen
>> {% 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_,
though.
> 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.
Bruno Desthuilliers
>>> 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...
Terry Reedy
>
> 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 <% ...>.
Terry Jan Reedy
Dotan Cohen
>> 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.
Dotan Cohen
> 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 <% ...>.
>
Thanks, Terry, that should save me some time.
Robert Kern
>>> 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 ?-)
>
> 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:
http://pypi.python.org/pypi/Breve/
--
Robert Kern
"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
erob
> 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.
erob
"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
Dotan Cohen
>> 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.
mario ruggier
database and Python 3, all the following have been available for
Python 3 since the day Python 3.0 was released:
QP, a Web Framework
http://pypi.python.org/pypi/qp/
Durus, a Python Object Database (the "default" in qp, for user
sessions, etc)
http://pypi.python.org/pypi/Durus/
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)
For the record, you may see the list of all pypi packages availabe for
Python 3 at:
http://pypi.python.org/pypi?:action=browse&show=all&c=533
m.
rustom
> 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 %
Bruno Desthuilliers
> 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).
rustom
42.desthuilli...@websiteburo.invalid> wrote:
> rustom a écrit :
I realised that that link
http://simonwillison.net/2003/Jul/28/simpleTemplates/
was written in 2003
Subsequently python has sprouted something explicitly templateish
http://docs.python.org/library/string.html#template-strings
Bruno Desthuilliers
> On Nov 5, 2:23 pm, Bruno Desthuilliers <bruno.
> 42.desthuilli...@websiteburo.invalid> wrote:
>>
>>> 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).
>
> I realised that that link
> http://simonwillison.net/2003/Jul/28/simpleTemplates/
> was written in 2003
>
> Subsequently python has sprouted something explicitly templateish
> http://docs.python.org/library/string.html#template-strings
Still poor man's template. Just don't hope to do any realworld web
templating with this.
rustom
42.desthuilli...@websiteburo.invalid> wrote:
> rustom a écrit :
>
>
>
> > On Nov 5, 2:23 pm, Bruno Desthuilliers <bruno.
> > 42.desthuilli...@websiteburo.invalid> wrote:
>
> >>> 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).
>
> > I realised that that link
> >http://simonwillison.net/2003/Jul/28/simpleTemplates/
> > was written in 2003
>
> > Subsequently python has sprouted something explicitly templateish
> >http://docs.python.org/library/string.html#template-strings
>
> 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.
Alan Harris-Reid
Regards,
Alan