PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
it's written by Phillip Eby who put a lot of effort in it to make it
acceptable to very diverse web frameworks. The PEP has been well
received by web framework makers and users.
As a supplement to the PEP, Phillip has written a
> I'm inviting people to discuss the addition of wsgiref to the standard
> library. I'd like the discussion to be finished before a3 goes out;
+1.
I think it's faily low-risk. WSGI has been discussed and implemented
for well over a year; there are many working implementations of the
spec. Addin
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
___
Guido van Rossum wrote:
> PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
> it's written by Phillip Eby who put a lot of effort in it to make it
> acceptable to very diverse web frameworks. The PEP has been well
> received by web framework makers and users.
>
> As a supplemen
On 4/28/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I'd like to include paste.lint with that as well (as wsgiref.lint or
> whatever). Since the last discussion I enumerated in the docstring all
> the checks it does. There's still some outstanding issues, mostly where
> I'm not sure if it is too
Guido van Rossum wrote:
>> I think another useful addition would be some prefix-based dispatcher,
>> similar to paste.urlmap (but probably a bit simpler):
>> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
>
>
> IMO this is getting into framework design. Perhaps something like this
> could
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
>Guido van Rossum wrote:
> > PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
> > it's written by Phillip Eby who put a lot of effort in it to make it
> > acceptable to very diverse web frameworks. The PEP has been well
> > receiv
It still looks like an application of WSGI, not part of a reference
implementation. Multiple apps looks like an advanced topic to me; more
something that the infrastructure (Apache server or whatever) ought to
take care of.
I don't expect you to agree with me. But I don't expect you to be able
to
Guido van Rossum wrote:
> It still looks like an application of WSGI, not part of a reference
> implementation. Multiple apps looks like an advanced topic to me; more
> something that the infrastructure (Apache server or whatever) ought to
> take care of.
I don't understand the distinction between
At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
>It still looks like an application of WSGI, not part of a reference
>implementation. Multiple apps looks like an advanced topic to me; more
>something that the infrastructure (Apache server or whatever) ought to
>take care of.
I'm fine with a s
On 4/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> If it's small enough, I'd say to add this mapper to wsgiref.util, or if
> Guido is strongly set against it being in the code, we should at least put
> it in the documentation as an example of how to use 'shift_path_info()' in
> wsgiref.util.
Phillip J. Eby wrote:
>> I'd like to include paste.lint with that as well (as wsgiref.lint or
>> whatever). Since the last discussion I enumerated in the docstring all
>> the checks it does. There's still some outstanding issues, mostly where
>> I'm not sure if it is too restrictive (marked with
I'm starting to play with WSGI, and I'd really like to find a
reasonable WSGI server implementation which will run as a Windows
service. I had a go with the CherryPy (2.2.1) WSGI server, and it
didn't seem to play nicely with the standard run-cherrypy-as-a-service
code I've used before. I may have
Support for Windows services is part of win32all, not core Python.
--Guido
On 4/28/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> I'm starting to play with WSGI, and I'd really like to find a
> reasonable WSGI server implementation which will run as a Windows
> service. I had a go with the CherryPy
Phillip J. Eby wrote:
> At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
>
>> It still looks like an application of WSGI, not part of a reference
>> implementation. Multiple apps looks like an advanced topic to me; more
>> something that the infrastructure (Apache server or whatever) ought to
FYI, Paul, I think Guido mistook your message as being in the "adding
wsgiref to the stdlib" thread. :)
As for your question, I think there's an IIS WSGI implementation. It's
also possible that Twisted or Zope have WSGI servers suitable for use as a
Windows service.
At 02:00 PM 4/28/2006 -
At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
>I don't see why not to use prefix matching. It is more consistent with
>the handling of the default application ('', instead of a method that
>needs to be overridden), and more general, and the algorithm is only
>barely more complex and not what I'd
On 4/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Support for Windows services is part of win32all, not core Python.
Sorry, I don't think I made my request clear. I'm looking for WSGI
server implementations, and in particular ones which can be made to
work as Windows services. The service
Phillip J. Eby wrote:
> At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
>
>> I don't see why not to use prefix matching. It is more consistent with
>> the handling of the default application ('', instead of a method that
>> needs to be overridden), and more general, and the algorithm is only
>> b
On Fri, Apr 28, 2006 at 02:36:11PM -0400, Phillip J. Eby 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/
->
At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>It will still be only a couple lines less than prefix matching.
That's beside the point. Prefix matching is inherently a more complex
concept, and more likely to be confusing, without introducing much in the
way of new features. If I want to dis
At 04:34 PM 4/28/2006 -0700, Titus Brown wrote:
>Hi, Phillip,
>
>I'm getting this error when I run the tests, with both Python 2.3 and
>2.4:
>
>==
>FAIL: testHeaderFormats (wsgiref.tests.test_handlers.HandlerTests)
>---
Phillip J. Eby wrote:
> At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>> It will still be only a couple lines less than prefix matching.
>
> That's beside the point. Prefix matching is inherently a more complex
> concept, and more likely to be confusing, without introducing much in
> the way
At 07:48 PM 4/28/2006 -0500, Ian Bicking wrote:
>One is not more complex than the other.
The implementation has more moving parts, but I was talking about
conceptual complexity.
The most common web servers do not match path prefixes, they have
directories and files. You can't have /foo/bar wit
24 matches
Mail list logo
