Web development with Python 3.1
bruno.42.desthuilliers at websiteburo.invalid
Thu Oct 29 09:31:51 CET 2009
Dotan Cohen a écrit :
>>> 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
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
>>> I think I mentioned that, but I apologize for being
>> 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
>> 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,
> but "saves you coding time down the line" is a lot more
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.
More information about the Python-list