Python on the Web
Phil
reason I seem to not be picking something up.
I am a graphical person, which is probably the reason I haven't found
my answer.
May somebody please confirm if my diagram accurately represents the
stack, generally speaking.
http://i26.tinypic.com/1fe82x.png
Even if that is the case, I'm having a hard time understanding the
differences. I guess wsgiref has absolutely nothing to do with FCGI/
SCGI/CGI and simply receives and responds to HTTP requests following
the WSGI specification? Does it just spawn a new thread for each
request? If so, then how is this any different than a production
server with FCGI?
The way I am understanding the 'Production' side of that picture is
that the web server (eg. lighttpd) creates a single FCGI process. The
FCGI process is actually the entry point of the Framework/Application
which sets up Flup's WSGIServer, being the interface between FCGI and
the Framework/Application? What I mean is, it is just the code that
the web server loads to start with, example...
from flup.server.fcgi import WSGIServer
from app import application
WSGIServer(application).run()
... Then for each HTTP request, Flup's WSGIServer creates a new thread
to handle the request?
As I've read elsewhere, "These days, FastCGI is never used directly.
Just like mod_python it is only used for the deployment of WSGI
applications." As far as I understand, the main (or only?) reasoning
for this is because WSGI makes Python applications easier to deploy
without having to worry about whether using FCGI/SCGI/CGI.
What would be involved to run Python on the web using FCGI without
WSGI? I can feel the flames already. This isn't the only reason I want
to know, but one reason is that I want to use Python 3.1 and as I
understand, this will have to wait for the WSGI 2.0 specification to
ensure time isn't wasted.
I apologize if the questions are ridiculous. I've just recently got
into web programming and it seems that in order for me to use Python,
I need a deep understanding of web servers, HTTP, FCGI, etc. I have
more questions but they go more off topic, so I will save it for
another thread, another day.
I realize there is a large number of questions, so thanks for any help.
Robert Kern
> I've seen lots of web sites explaining everything, but for whatever
> reason I seem to not be picking something up.
> I am a graphical person, which is probably the reason I haven't found
> my answer.
> May somebody please confirm if my diagram accurately represents the
> stack, generally speaking.
>
> http://i26.tinypic.com/1fe82x.png
>
> Even if that is the case, I'm having a hard time understanding the
> differences. I guess wsgiref has absolutely nothing to do with FCGI/
> SCGI/CGI and simply receives and responds to HTTP requests following
> the WSGI specification?
Correct.
> Does it just spawn a new thread for each
> request?
No, it is single-threaded.
> If so, then how is this any different than a production
> server with FCGI?
>
> The way I am understanding the 'Production' side of that picture is
> that the web server (eg. lighttpd) creates a single FCGI process. The
> FCGI process is actually the entry point of the Framework/Application
> which sets up Flup's WSGIServer, being the interface between FCGI and
> the Framework/Application? What I mean is, it is just the code that
> the web server loads to start with, example...
> from flup.server.fcgi import WSGIServer
> from app import application
> WSGIServer(application).run()
> ... Then for each HTTP request, Flup's WSGIServer creates a new thread
> to handle the request?
Something like that, yes.
> As I've read elsewhere, "These days, FastCGI is never used directly.
> Just like mod_python it is only used for the deployment of WSGI
> applications." As far as I understand, the main (or only?) reasoning
> for this is because WSGI makes Python applications easier to deploy
> without having to worry about whether using FCGI/SCGI/CGI.
Yes, that is the primary reason for WSGI, in my mind. There are other things
like the composability of applications, but the decoupling of application
authoring from deployment is the sine qua non, in my opinion.
> What would be involved to run Python on the web using FCGI without
> WSGI? I can feel the flames already. This isn't the only reason I want
> to know, but one reason is that I want to use Python 3.1 and as I
> understand, this will have to wait for the WSGI 2.0 specification to
> ensure time isn't wasted.
I am willing to bet that the FCGI libraries haven't been upgraded to Python 3.x,
either. I suspect that the most 3.x-updating work will be going into WSGI and
the adapters. E.g.
http://www.saddi.com/software/news/archives/64-Dabbling-in-Python-3.0.html
You may want to rethink the Python 3.x requirement, though. It will probably be
much less a waste of your time to write your app using a framework like Django
or Pylons on Python 2.x and then upgrade to Python 3.x when they do.
> I apologize if the questions are ridiculous. I've just recently got
> into web programming and it seems that in order for me to use Python,
> I need a deep understanding of web servers, HTTP, FCGI, etc. I have
> more questions but they go more off topic, so I will save it for
> another thread, another day.
Knowing something about HTTP will certainly help get into the right mindset to
know what limitations and capabilities web apps can have.
Typically, though, you use a framework that abstracts most of this stuff away
from you. You usually only need to delve into the details in very specific
circumstances.
--
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
Phil
My interest in Python 3.1 was actually to develop a framework. Again,
I can feel the flames. :) I understand there are enough frameworks but
I actually have no applications that I wish to develop. I enjoy
developing these kinds of things from scratch as a learning
experience.
I've been doing fine with 2.x and WSGI, even without understanding
half of this stuff. It is actually my first Python project. Haha. I
just have my own design philosophies that I wish to experiment with.
Python 3.x just makes everything nicer with UNICODE, etc.
Although you've been helpful with almost all of the mentioned
concerns, I am still looking for more details on some of the questions
I've asked. So, if others stumble upon this post, feel free to
contribute further.
Thanks again.
alex23
> My interest in Python 3.1 was actually to develop a framework. Again,
> I can feel the flames. :) I understand there are enough frameworks but
> I actually have no applications that I wish to develop.
No offense intended, but that's probably the worst approach to take.
Frameworks created for the sake of creating a framework, as opposed to
those written to meet a defined need, tend to be the worst examples of
masturbatory coding.
Phil
No offense taken. I understand your concern. I actually do have some
important design decisions I wish to meet. It has sort of been a
process of evaluating the things I love and hate most from existing
frameworks.
Graham Dumpleton
I would in part actually disagree with that.
The problem with people creating frameworks to meet some defined need
is that they often implement only just enough of that framework to
meet that need and nothing more. End result is that the framework is
more often than not ever fleshed out enough to be of much use to
anyone else. Its existence though just pollutes the Internet with more
crap that one has to wade through.
Since there is already a plethora of good frameworks out there, if
writing an application, you are better of using one of the existing
frameworks. If interested in working at the framework level, you would
still be much better off looking at the existing frameworks, first
learn how they work and then consider contributing to them, rather
than implementing your own.
For some related reading, see:
http://lucumr.pocoo.org/2009/7/30/nih-in-the-wsgi-world
As far as low level framework (or anti frameworks), suggest looking at
Werkzeug, Paste/Pylons and bobo.
I'll comment more on original message later.
Graham
Graham Dumpleton
On Aug 26, 11:09 am, Phil <phil...@gmail.com> wrote:
> I've seen lots of web sites explaining everything, but for whatever
> reason I seem to not be picking something up.
> I am a graphical person, which is probably the reason I haven't found
> my answer.
> May somebody please confirm if my diagram accurately represents the
> stack, generally speaking.
>
> http://i26.tinypic.com/1fe82x.png
>
> Even if that is the case, I'm having a hard time understanding the
> differences. I guess wsgiref has absolutely nothing to do with FCGI/
> SCGI/CGI and simply receives and responds to HTTP requests following
> the WSGI specification?
Technically it receives and responses to request based on HTTP
specification, not WSGI specification. The underlying HTTP server
translates to and communicates with a Python web application using the
WSGI interface.
> Does it just spawn a new thread for each
> request? If so, then how is this any different than a production
> server with FCGI?
I would describe there as being four major ways that WSGI can be
hosted. These are:
1. Custom build HTTP/WSGI server written in Python. Production quality
examples are CherryPy WSGI server and Paste HTTP server. You shouldn't
use wsgiref for anything but very simple stuff.
2. Per request process execution by way of CGI and a CGI/WSGI adapter.
This could be under Apache or any other web server which supports CGI.
3. Module that embeds Python interpreter into a C based web server.
Example are mod_wsgi and mod_python for Apache. Note that mod_python
would infrequently be used to host WSGI and doesn't include its own
WSGI adapter. These days mod_wsgi for Apache would be used. Processes
in this would be persistent.
4. Module in a web server that allows one to communicate using a
custom protocol with a separate persistent web application process
hosting the web application through a WSGI interface. This convers
FASTCGI, SCGI and AJP. The mod_wsgi module for Apache has a hybrid
mode which work in a similar way but uses an internal protocol.
Amongst these, there are many variations as far as number of process
and threads. For a bit of discussion about this in relation to
mod_wsgi read:
http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
> The way I am understanding the 'Production' side of that picture is
> that the web server (eg. lighttpd) creates a single FCGI process.
FASTCGI isn't restricted to a single process, nor single threading.
Whether a particular implementation allows for the variations depends
on the implementation.
> The
> FCGI process is actually the entry point of the Framework/Application
> which sets up Flup's WSGIServer, being the interface between FCGI and
> the Framework/Application? What I mean is, it is just the code that
> the web server loads to start with, example...
> from flup.server.fcgi import WSGIServer
> from app import application
> WSGIServer(application).run()
> ... Then for each HTTP request, Flup's WSGIServer creates a new thread
> to handle the request?
>
> As I've read elsewhere, "These days, FastCGI is never used directly.
Even back in time, I don't think it was really ever used as a generic
interface that people worked with directly, there was always a more
usable layer built on top of it.
> Just like mod_python it is only used for the deployment of WSGI
> applications.
The mod_python module isn't used just for WSGI applications and is
probably rarely used for them. This is because mod_python has its own
interface for building web applications. It also has abilities to hook
into Apache request handling phases, meaning it can do more than host
a a content handler/web application.
> As far as I understand, the main (or only?) reasoning
> for this is because WSGI makes Python applications easier to deploy
> without having to worry about whether using FCGI/SCGI/CGI.
WSGI provides for portability, it isn't necessarily easier to use than
mod_python.
> What would be involved to run Python on the web using FCGI without
> WSGI? I can feel the flames already.
No, you really don't want to do that.
> This isn't the only reason I want
> to know, but one reason is that I want to use Python 3.1 and as I
> understand, this will have to wait for the WSGI 2.0 specification to
> ensure time isn't wasted.
Then look at mod_wsgi. It already has support for Python 3.X. Some
aspects of how it implements WSGI 1.0 may change, but will not be too
much and details are being sorted out in the back rooms as we speak.
See:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0300
The other option is CherryPy WSGI server as that is close to a Python
3.X release as well, as I perceive it.
I wouldn't bother waiting for WSGI 2.0. That is more of a pipe dream.
There will be an updated WSGI 1.0 for Python 3.0.
Graham
Bruno Desthuilliers
> I've seen lots of web sites explaining everything, but for whatever
> reason I seem to not be picking something up.
> I am a graphical person, which is probably the reason I haven't found
> my answer.
> May somebody please confirm if my diagram accurately represents the
> stack, generally speaking.
>
> http://i26.tinypic.com/1fe82x.png
Seems correct.
> Even if that is the case, I'm having a hard time understanding the
> differences. I guess wsgiref has absolutely nothing to do with FCGI/
> SCGI/CGI and simply receives and responds to HTTP requests following
> the WSGI specification?
Yeps.
> Does it just spawn a new thread for each
> request?
Not AFAICT.
> The way I am understanding the 'Production' side of that picture is
> that the web server (eg. lighttpd) creates a single FCGI process. The
> FCGI process is actually the entry point of the Framework/Application
> which sets up Flup's WSGIServer, being the interface between FCGI and
> the Framework/Application? What I mean is, it is just the code that
> the web server loads to start with, example...
> from flup.server.fcgi import WSGIServer
> from app import application
> WSGIServer(application).run()
> ... Then for each HTTP request, Flup's WSGIServer creates a new thread
> to handle the request?
I didn't bother reading Flup's source code, but I suppose this might be
the case.
> As I've read elsewhere, "These days, FastCGI is never used directly.
> Just like mod_python it is only used for the deployment of WSGI
> applications." As far as I understand, the main (or only?) reasoning
> for this is because WSGI makes Python applications easier to deploy
> without having to worry about whether using FCGI/SCGI/CGI.
Nor about which web server you use (Apache, lighthttpd, whatever).
> What would be involved to run Python on the web using FCGI without
> WSGI? I can feel the flames already. This isn't the only reason I want
> to know, but one reason is that I want to use Python 3.1 and as I
> understand, this will have to wait for the WSGI 2.0 specification to
> ensure time isn't wasted.
My humble opinion (based on years of experience in both Python and web
programming) is that you're taking the wrong approach. I can only second
Robert Kern here: use an existing, well maintained wsgi-compliant
framework like Django, Pylons etc, and wait for the framework to be
ported to python 3.x. Any other solution will almost certainly end up
needing a complete rewrite anytime soon.
> I apologize if the questions are ridiculous. I've just recently got
> into web programming and it seems that in order for me to use Python,
> I need a deep understanding of web servers, HTTP, FCGI, etc.
Programming for the web - whatever the language & techno - indeed
require a deep (or at least correct) understanding of HTTP and web
servers, yes. Even with the abstraction layers provided by frameworks,
you still need to understand how the whole damn thing works, what's an
HTTP resquest & response and quite a few other things as well.
Phil
I have looked at the links that have been provided, although I have
seen most of them in the past month or so that I've been looking into
this stuff. I do agree with most of the things Armin stated in that
NIH post. I agree with everybody in this thread so far. If I wanted to
write an application, I would use an existing framework and wait for
it to be ported to 3.x. However, I do not have the need to write a web
application at this time, and creating blogs or other applications I
do not need for fun is getting old.
My reasoning for working on my own instead of following the 'NIH'
concept or contributing to an existing framework is because I have
experimented with many existing frameworks and I have figured out what
I like/dislike, and have envisioned my own design that I feel would
work potentially better for others, or at least newcomers. Things like
this are fun for me, and I do not mind the challenge. I don't want to
pollute the web with (sigh) 'another framework', but it would be fun
for me to write it and get some feedback. I would love for people like
you, Armin, and others who take a look at the various frameworks that
pop up seemingly every day, to look at my (hypothetical) framework and
just rip it apart with (constructive) criticism. That is just the way
I do things, whether the community agrees with it or not. The reason I
was asking about Python 3 on the web was just because I like some of
the changes that have been made, and would like to use it for my
framework. That is when I realized that I was absolutely clueless
about the details of how Python, or any language, works on the web.
Graham, regarding number 3 in your list of ways to host WSGI: I
haven't really looked into mod_wsgi at all, but basically it sounds
like the web server would be running this embedded module. That module
would then serve the function of both FCGI and the 'WSGI Server' in my
diagram? That actually sounds really neat. Unfortunately I missed this
because I've been hooked on lighttpd, as the minimalist I am.
Here are the things I am still confused with:
1) Why do I not want to consider running Python on the web with FCGI,
without WSGI? You said 'no' straight up, no questions asked. I would
imagine that there is a good reason of course, as you've been in this
field for a long time. I just feel more comfortable understanding why.
From my understanding, the only real purpose of WSGI is to remain
independent of FCGI/SCGI/CGI/AJP (whatever that is) and the web server
it is run on. However, 99.9% of the discussion I see with Python on
the web is around FCGI. So for example, lets say everybody used FCGI.
All that would be left to deal with is web server independence. Now
this is what I don't get, I thought that FCGI itself was supposed to
be the protocol that deals with web server independence. Maybe I just
need to re-read entire WSGI specification to understand, along with
all the details of FCGI. There are just so many details regarding web
servers, FCGI, and WSGI that it is hard to absorb it all and see how
it works together. That is why I tried to create the diagram, but it
doesn't provide enough details. And those are the details I am
missing. I've been trying to find a simple diagram or explaination of
the process a request takes to make a response, from HTTP all the way
up to the application, to the the user.
2) In the development stack, the 'WSGI Server' seems to take on the
role of the web server (dealing with HTTP specification), skips FCGI,
and deals with the WSGI specification. Then, the 'WSGI Server' in the
production stack (eg. Flup, CherryPy, etc) only deals with FCGI and
WSGI specification, because the HTTP is already taken care of by the
web server?
Graham Dumpleton
Because FASTCGI is a wire protocol for socket communications and not a
programming interface. As such, you would only be creating much more
work for your self as you would need to implement a whole lot of code
to handle the protocol and then still put a usable interface on top of
it. You would also have to come up with what that usable interface
should be as well. WSGI already provides that low level interface.
> I just feel more comfortable understanding why.
> From my understanding, the only real purpose of WSGI is to remain
> independent of FCGI/SCGI/CGI/AJP (whatever that is) and the web server
> it is run on. However, 99.9% of the discussion I see with Python on
> the web is around FCGI.
99.9% of the discussion about Python on the web is not around FASTCGI.
Even if there is quite a bit of discussion, it is because
documentation on hosting Python on FASTCGI via flup is virtually non
existent and so many people have a lot of trouble getting it to work
due to peculiarities of different FASTCGI implementations. The
dicusssion is therefore because people have problems with it, or feel
the need to blog about how they finally got it to work. So, FASTCGI
may be the only way for commodity web hosting, but it certainly isn't
for self managed servers where mod_wsgi, mod_python and mod_proxy type
solutions are going to be preferred. The latter are better documented
or easier to setup and so why you possibly don't see as much
discussion. In other words, people who get things working easily don't
need to ask questions.
> So for example, lets say everybody used FCGI.
> All that would be left to deal with is web server independence. Now
> this is what I don't get, I thought that FCGI itself was supposed to
> be the protocol that deals with web server independence. Maybe I just
> need to re-read entire WSGI specification to understand, along with
> all the details of FCGI. There are just so many details regarding web
> servers, FCGI, and WSGI that it is hard to absorb it all and see how
> it works together. That is why I tried to create the diagram, but it
> doesn't provide enough details. And those are the details I am
> missing. I've been trying to find a simple diagram or explaination of
> the process a request takes to make a response, from HTTP all the way
> up to the application, to the the user.
FASTCGI fills a role, but is not essential. Personally I feel that
whole concept of FASTCGI/SCGI/AJP needs a refresh and modernised with
better hosting support for it.
> 2) In the development stack, the 'WSGI Server' seems to take on the
> role of the web server (dealing with HTTP specification),
It doesn't have to. Some servers may have a clear line between the two
with WSGI being a properly distinct layer on top.
> skips FCGI,
> and deals with the WSGI specification. Then, the 'WSGI Server' in the
> production stack (eg. Flup, CherryPy, etc) only deals with FCGI and
> WSGI specification, because the HTTP is already taken care of by the
> web server?
Graham
Phil
this before but the results are amazing.
I will definitely consider trying mod_wsgi when I get a chance. I like
the approach taken with it. It is unfortunate that I completely missed
all Apache related material because I was using lighttpd. Is there no
mod_wsgi for lighttpd? I guess I could always just Google that myself.
Thanks again for the help.
Graham Dumpleton
There is no mod_wsgi for lighttpd and suggest there never will be.
WSGI doesn't lend itself to working on top of an event driven system.
Someone did get a mod_wsgi going on nginx, which is also event driven,
but it has limitations due to possibility of blocking other traffic to
web server. See:
http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html
Graham
Bruno Desthuilliers
(snip)
> However, 99.9% of the discussion I see with Python on
> the web is around FCGI.
May I suggest you spend some time reading django-users and django-dev on
google groups ? (and that's only *one* of the way-too-many Python web
frameworks).
Phil
Google search last night before I saw your response. It was very
informative.
Bruno, I will take a look at those groups to expand my knowledge. When
I gave that arbitrary percentage, I was basing it off of the
information I had seen with regards to launching applications built
with existing frameworks using lighttpd. I do realize I was missing a
lot of information by looking up something that specific. I also
understand that there are enough frameworks. That still won't change
my mind. I do not want to write a web application, otherwise I would
use an existing framework as suggested. I just wanted to experiment
and see what kind of framework I could develop with some ideas I had
in mind. The original post was mostly just because I was having a
difficulty understanding some lower level concepts as a result of
trying to get Python 3 on the web before figuring out that it wasn't
quite ready for that. I just really like some of the new features of
Python 3, and most importantly, unicode compliance is just that much
straight forward in my opinion.
Aahz
Phil <phi...@gmail.com> wrote:
>
>My interest in Python 3.1 was actually to develop a framework. Again,
>I can feel the flames. :) I understand there are enough frameworks but
>I actually have no applications that I wish to develop. I enjoy
>developing these kinds of things from scratch as a learning
>experience.
Well, there's a standard joke that just as people learning Scheme write
a new language (following SICP), people learning Python write a new web
framework. That's why there are so many of them.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"I support family values -- Addams family values" --www.nancybuttons.com
Phil
impression that you think I haven't been reading the web where nearly
every blog post complains about the abundance of Python frameworks.
The thing is, most of the frameworks being commented on in such a way
are 'microframeworks' that provide next to nothing. I'm do not mean to
say anything negative about them, but I strongly feel that my approach
will be much more functional without having to include, or at least a
good starting point for newcomers to both Python and web programming.
The ideas I had for mine lied somewhere in between a full stack
framework and a minimalist approach like said microframeworks.
Bruno Desthuilliers
> When
> I gave that arbitrary percentage, I was basing it off of the
> information I had seen with regards to launching applications built
> with existing frameworks using lighttpd. I do realize I was missing a
> lot of information by looking up something that specific.
Indeed !-)
> I also
> understand that there are enough frameworks. That still won't change
> my mind. I do not want to write a web application, otherwise I would
> use an existing framework as suggested. I just wanted to experiment
> and see what kind of framework I could develop with some ideas I had
> in mind.
I wrote quite a couple web and non web frameworks myself - all ending up
in the trash can FWIW, but it certainly has been a very educative
experience by itself.
> I just really like some of the new features of
> Python 3, and most importantly, unicode compliance is just that much
> straight forward in my opinion.
If you're only writing your framework for learning purposes, you could
as well go with Python 3, and implement everything from the ground up
(not a trivial task FWIW).
John Nagle
> A few additional comments on top of what others have said.
>
> On Aug 26, 11:09 am, Phil <phil...@gmail.com> wrote:
>> As I've read elsewhere, "These days, FastCGI is never used directly.
Actually, FCGI works quite well. Sitetruth's AdRater
(http://www.sitetruth.com/downloads/adrater.html) uses
FCGI and Python on the server.
FCGI is basically CGI with process reusability. Each
app gets its own process in its own address space with its
own global interpreter lock. mod_fcgi in Apache keeps a
supply of such processes around, launching additional ones if there's
heavy request traffic and shutting down existing ones when there
isn't. Each process handles one transaction after another,
so, unlike CGI, you're not spending all your time loading Python
and its modules.
Here's the main loop of a real FCGI application. This uses a small
WSGI library on the Python side. No "framework" is involved.
#!/usr/local/bin/python
...
from fcgi import WSGIServer
import MySQLdb
db = None # database connection, held open for life of FCGI
#
# The application
#
def QuickSitetruthQuery(environ, start_response):
global db # static global - active database handle
try:
if db : # if previously attached
try :
db.ping() # test whether connection is still up
# handle loss of database connection
except MySQLdb.OperationalError, message:
db = None # we lost database connection
if db is None : # if no valid database handle
db = miscutils.dbattach(kdbfile) # connect to database
status = '200 OK' # normal status
headers = [('Content-type','text/xml'), ('charset','utf-8')]
reqlist = cgi.parse_qsl(environ['QUERY_STRING']) # Parse params
priority = 1 # priority of request
sourceip = environ['REMOTE_ADDR'] # get IP address of client
urls = [] # list of URLs to check
for item in reqlist : # for all items
(key, value) = item # extract item
if key.lower() == 'url' : # want all "url" items
urls.append(value)
elif key.lower() == 'priority' : # if priority
priority = int(value) # get priority value
# Make request; no waiting, no details
outstr = InfoDisplay.getratingXMLquick(db, kdbfile, urls,
priority, sourceip) # get the rating XML, never wait
start_response(status, headers) # compose result
s = kprefixxml + outstr + ksuffixxml # construct output XML
return [s.encode('utf8')] # encode as UTF8
except Exception, message: # if trouble, report to user
# Error handling
status = "500 Internal Error on Server"
response_headers = [("Content-type","text/html")]
start_response(status, response_headers)
s = "<h1>Internal error - request not processed.</h1>\n\n"
+ traceback.format_exc()
s = s.replace("\n","<br>") # convert to HTML
return [s]
#
# Main FCGI program
#
WSGIServer(QuickSitetruthQuery).run()
John Nagle
> If you're only writing your framework for learning purposes, you could
> as well go with Python 3, and implement everything from the ground up
> (not a trivial task FWIW).
Python 3 isn't ready for prime time on web servers. Too many major modules,
haven't been ported yet. Twisted and Django are now available up to Python 2.6;
MySQLdb is available only up to Python 2.5. So the basics for web work aren't
ready yet.
Python 2.5 is more or less the "stable" version of Python for production
use at the moment. 2.6 is a transition version to 3.0.
John Nagle
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>> If you're only writing your framework for learning purposes, you could
>> as well go with Python 3, and implement everything from the ground up
>> (not a trivial task FWIW).
>
> Python 3 isn't ready for prime time on web servers. Too many major
> modules,
> haven't been ported yet.
Which ones (sorry, still using 2.5 at work so I didn't bother that much
with 2.6 so far) ?
> MySQLdb is available only up to Python 2.5. So the basics
> for web work aren't
> ready yet.
I wouldn't label MySQLdb as "a basic for web work" - I mean, something
you just can't do without !-)
Ed Singleton
> Frameworks created for the sake of creating a framework, as opposed to
> those written to meet a defined need, tend to be the worst examples of
> masturbatory coding.
Indeed, but masturbation is perfectly healthy and acceptable, and we
all do it every now and then. It is however, much like the framework
in question, best kept private and not made public.
Ed
Bruno Desthuilliers
+1 QOTW !-)
Bruno Desthuilliers
(snip)
> MySQLdb is available only up to Python 2.5.
Huh ???
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
/var/lib/python-support/python2.6/MySQLdb/__init__.py:34:
DeprecationWarning: the sets module is deprecated
from sets import ImmutableSet
>>> cnx = MySQLdb.connect(db='cress', user='cress', passwd='cress')
>>> cursor = cnx.cursor()
>>> cursor.execute("SELECT id_article, titre FROM spip_articles")
28L
>>> for row in cursor:
... print row
...
(1L, '01. Sensibilisation')
(2L, '02. Gestation')
(3L, '03. Lancement')
(4L, '04. D\xe9veloppement')
(5L, '01. Sensibilisation')
(6L, '02. Gestation')
(7L, '03. Lancement')
(8L, '04. D\xe9veloppement')
(9L, '01. Sensibilisation')
(10L, '02. Gestation')
(11L, '03. Lancement')
(12L, '04. D\xe9veloppement')
(13L, 'Nouvel article')
(14L, 'Nouvel article')
(15L, '01. Les principes fondateurs d\x92une coop\xe9rative')
(16L, '02. C\x92est quoi une COOPERATIVE ?')
(17L, '10. Les principes fondamentaux de l\x92Economie sociale et
solidaire')
(18L, '20. Les familles de l\x92Economie sociale et solidaire ')
(19L, 'Article 1')
(20L, 'Article 2')
(21L, 'Article 3')
(22L, 'Article 4')
(23L, 'Article 5')
(24L, 'Lancement du nouveau site de la CRESS')
(25L, 'Mise \xe0 jour des Formations')
(26L, "La CRESS au Salon de l'Emploi")
(27L, '01. Pr\xe9sentation')
(28L, '20. Les formations universitaires BAC +3')
>>> cursor.close()
>>> cnx.close()
>>>
Seems to work just fine here...