Alice Bevan–McGregor al...@... writes:
[1] http://bit.ly/e7rtI6
So, while we are at it, could we get rid of the CGI server example in this new
SWGI spec?
This is 2011, and we should promote modern idioms, not encourage people to do
1995 Web programming. 10 years ago, CGI was already frown
Agree, i develop an excelent wsgi server in Py3k, without use the cgi
library to extract the data, so is better if in the manual kills the
part that indicate use the cgi lib to extract the data.
2011/1/4, Antoine Pitrou solip...@pitrou.net:
Alice Bevan–McGregor al...@... writes:
[1]
At 12:43 PM 1/4/2011 +, Antoine Pitrou wrote:
Alice BevanMcGregor al...@... writes: [1]
http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
the CGI server example in this new SWGI spec? This is 2011, and we
should promote modern idioms, not encourage people to do 1995 Web
CGI is by far the quickest and easiest way to write and deploy very simple web
site scripts. As you move to improve Python for important industrial strength
web programming, why not also continue to support quick and dirty web
interactivity scripts?
Ron Stephens
Sent from my iPhone
On Jan
CGI may be old fashioned, but in my opinion Ron got the point. And for simple
applications CGI is fast enough.
I don't want to miss this option.
Klaus.
--
Am 04.01.2011 um 18:57 schrieb hid...@gmail.com:
Because CGI is an old fashion way to make the things and is very different
from the
Right. Note that App Engine does not copy the full CGI mechanism -- it
doesn't start a new process for each request. But it does use
os.environ to set the request parameters for each request. However, in
practice, all but the simplest test apps use a custom WSGI bridge, and
we are considering
On 5 January 2011 07:04, James Y Knight f...@fuhm.net wrote:
Back to the subject of this thread: A simple CGI server is useful because
it's simple enough that you can include it in the spec, to demonstrate how to
handle various bits of WSGI. And anyone writing a webserver understands CGI,
