headers
Luke Arno | 2 May 2006 06:04
Picon

Re: [Python-Dev] Adding wsgiref to stdlib

I don't pipe up much but dispatch has been on my
mind for a while as I have been working on this:

http://lukearno.com/projects/selector/

I think dispatching is best left as an (obvious) exercise
to the reader. What dispatching makes sense, what
metaphor or technique should be applied, is situational.

When I see other WSGI servers requiring a list of
prefix/app pairs in their init signature, I am put off.

The server's job is to translate HTTP (or SCGI, FCGI,
etc.) to WSGI. Just do that.

To me WSGI is not just the freedom of frameworks
interoperating, but the freedom _from_ frameworks.
The stack can be unbundled and I can pick the the
best thing for my needs at each layer, à la carte.

- Luke

http://lukearno.com/
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sylvain Hellegouarch | 2 May 2006 10:11
Gravatar

[Python-Dev] Adding wsgiref to stdlib

Hello all,

I've been following the discussion around adding wsgiref to the stdlib and
it sounds like a very good idea. However I'm a little concerned as it
seems only wsgiref has been suggested to be included. I wonder if you guys
intend to review other implementations before going ahead? I ask this
because the simple_server.py module of wsgiref says:

"""It has not been reviewed for security issues,
however, and we strongly recommend that you use a "real" web server for
production use.
"""

Therefore, I wonder what is the final purpose of such addition? Is it
merely to have default WSGI implementation that *might* not be scalable in
production?

I have nothing against wsgiref mind you. I'm fairly sure Phillip has done
a great job but I simply wanted to know if you would consider checking
other implemetations.

- Sylvain
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 2 comments |
headers
Paul Moore | 2 May 2006 15:48
Picon
Gravatar

Re: [Python-Dev] Adding wsgiref to stdlib

On 4/28/06, Phillip J. Eby <pje@...> wrote:
> At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote:
> >(I'm asking Phillip to post the URL for the current
> >source; searching for it produces multiple repositories.)
>
> Source browsing: http://svn.eby-sarna.com/wsgiref/
> Anonymous SVN:   svn://svn.eby-sarna.com/svnroot/wsgiref

I'm not sure how dumb a question this is, but bear with me :-)

>From reading this, it seems that there is no CGI-to-WSGI gateway in
wsgiref. Would it be worth adding one (or did I miss it)? I'm thinking
of a case where I have a WSGI application, but no easy way of hosting
anything other than CGI. In that situation, being able to wrap my
application in a CGI-to-WSGI gateway would be useful - and having one
in the standard library would avoid me having to cut and paste the
run_with_cgi code from PEP 333 into each of my scripts...

Does this make any sense?

Paul.
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Guido van Rossum | 2 May 2006 16:39
Favicon

Re: [Python-Dev] Adding wsgiref to stdlib

On 5/2/06, Sylvain Hellegouarch <sh@...> wrote:
> I've been following the discussion around adding wsgiref to the stdlib and
> it sounds like a very good idea. However I'm a little concerned as it
> seems only wsgiref has been suggested to be included. I wonder if you guys
> intend to review other implementations before going ahead? I ask this
> because the simple_server.py module of wsgiref says:
>
> """It has not been reviewed for security issues,
> however, and we strongly recommend that you use a "real" web server for
> production use.
> """
>
> Therefore, I wonder what is the final purpose of such addition? Is it
> merely to have default WSGI implementation that *might* not be scalable in
> production?
>
> I have nothing against wsgiref mind you. I'm fairly sure Phillip has done
> a great job but I simply wanted to know if you would consider checking
> other implemetations.

Anything that could be considered of sufficiently industrial strength
to be secure and scalable in production would necessarily be such a
large project, such a complex code base, and have such  different
release cycle that it would not make a good standard library
candidate. (Think mod_python, Twisted, Zope, Apache; think tail
wagging the doc.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sylvain Hellegouarch | 2 May 2006 17:13
Gravatar

Re: [Python-Dev] Adding wsgiref to stdlib


> Anything that could be considered of sufficiently industrial strength
> to be secure and scalable in production would necessarily be such a
> large project, such a complex code base, and have such  different
> release cycle that it would not make a good standard library
> candidate. (Think mod_python, Twisted, Zope, Apache; think tail
> wagging the doc.)

I was thinking into products that have shown good results over the last
past year and are far less complex than the ones you mention. There are
existing implementations that could be easily extracted from their
environment and might be better: CherryPy, Paste, Pylons, Colubrid, etc.
all offer what wsgiref provides (well to what I understand from wsgiref
code, Phillip could correct my knowledge here).

Nevertheless, it might be more useful to define the boundaries of
including a WSGI implementation to the stdlib before even choosing one.

AFAIK, WSGI is splitted into three distinct layers.

A web server
Some middlewares
An application

We will not include middlewares I believe.
I'm not sure I would see the point of adding a default WSGI application.

So we're left with the web server part to test and then see which is the
one filling the best the criteria folks around here may decide to
discriminate on.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 2 May 2006 17:32
Gravatar

Re: [Python-Dev] Adding wsgiref to stdlib

At 02:48 PM 5/2/2006 +0100, Paul Moore wrote:
>On 4/28/06, Phillip J. Eby <pje@...> wrote:
>>At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote:
>> >(I'm asking Phillip to post the URL for the current
>> >source; searching for it produces multiple repositories.)
>>
>>Source browsing: http://svn.eby-sarna.com/wsgiref/
>>Anonymous SVN:   svn://svn.eby-sarna.com/svnroot/wsgiref
>
>I'm not sure how dumb a question this is, but bear with me :-)
>
> From reading this, it seems that there is no CGI-to-WSGI gateway in
>wsgiref.

There is, sort of:

     from wsgiref.handlers import CGIHandler
     CGIHandler().run(app)

What the TODO is referring to is some kind of wrapper script that can be 
used to launch a deployed application.  It's pending there being some kind 
of deployment standard for WSGI.

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bicking | 2 May 2006 17:53
Gravatar

Re: [Python-Dev] Adding wsgiref to stdlib

Luke Arno wrote:
> I don't pipe up much but dispatch has been on my
> mind for a while as I have been working on this:
> 
> http://lukearno.com/projects/selector/
> 
> I think dispatching is best left as an (obvious) exercise
> to the reader. What dispatching makes sense, what
> metaphor or technique should be applied, is situational.

I don't think the idea is obvious to readers.  Prefix dispatching is 
also unique, in that it's the only kind of dispatching that can be 
represented fully in conventional WSGI (without other environ keys); 
though host matching also pretty much works.

Prefix matching also doesn't compete very actively with other 
dispatching techniques.  It's not enough to build a framework on, it 
represents a technique that already exists in lots of web servers

> When I see other WSGI servers requiring a list of
> prefix/app pairs in their init signature, I am put off.
> 
> The server's job is to translate HTTP (or SCGI, FCGI,
> etc.) to WSGI. Just do that.

This isn't being proposed as part of the server, just as a tool in 
wsgiref.  It's up to the user to use the dispatcher together with the 
server.  It's part of other servers,

> To me WSGI is not just the freedom of frameworks
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luke Arno | 2 May 2006 22:54
Picon

Re: [Python-Dev] Adding wsgiref to stdlib

On 5/2/06, Ian Bicking <ianb@...> wrote:
> Luke Arno wrote:
> > I don't pipe up much but dispatch has been on my
> > mind for a while as I have been working on this:
> >
> > http://lukearno.com/projects/selector/
> >
> > I think dispatching is best left as an (obvious) exercise
> > to the reader. What dispatching makes sense, what
> > metaphor or technique should be applied, is situational.
>
> I don't think the idea is obvious to readers.  Prefix dispatching is
> also unique, in that it's the only kind of dispatching that can be
> represented fully in conventional WSGI (without other environ keys);
> though host matching also pretty much works.
>

I think it is obvious.

I can't count the number of times I have seen a
novice web developer create a "master" PHP
script to push his/her whole application through in
an effort to take over dispatch. I think that it
is the most natural thing to do.

> Prefix matching also doesn't compete very actively with other
> dispatching techniques.  It's not enough to build a framework on, it
> represents a technique that already exists in lots of web servers
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Titus Brown | 4 May 2006 08:54
Picon
Favicon

wsgiref problems & quibbles

Hi, Phillip,

so I threw together a few WSGI apps recently, and used wsgiref to serve
them.  I ran into two problems, and had a few quibbles to raise as well.

===

First, a patch to fix the existing unit tests is attached.

===

Second, there's a bug in handlers.BaseHandler.finish_response, line 132.
The line:

        if not self.result_is_file() and not self.sendfile():

should read

        if not self.result_is_file() or not self.sendfile():
	                             ^^

Otherwise use of wsgi.file_wrapper fails to return any data.

I also can't find any place in the code where 'sendfile' is called to
actually send the file.  Should that 'if' statement have an 'else'??

Patch attached, along with 'break-wsgiref.py'.

===
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Bicking | 5 May 2006 00:04
Gravatar

Re: wsgiref problems & quibbles

Titus Brown wrote:
> 	or (if you still insist on the performance enhancement of
> 	keeping it under a separate module ;)
> 
> 	  s = wsgiref.simple_server.WSGIServer(host, port, app)

Shouldn't that be wsgiref.simpleserver, to make it fit PEP 8?

--

-- 
Ian Bicking  /  ianb@...  /  http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 0 comments |

Gmane