Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
Ian Bicking wrote: Phillip J. Eby wrote: At 02:32 PM 4/28/2006 -0500, Ian Bicking 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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py Ian, I see this is under the MIT license. Do you also have a PSF contributor agreement (to license under AFL/ASF)? If not, can you place a copy of this under a compatible license so that I can add this to the version of wsgiref that gets checked into the stdlib? I don't have a contributor agreement. I can change the license in place, or sign an agreement, or whatever; someone should just tell me what to do. I faxed in a contributor aggreement, and added this to the comment header of the file: # Also licenced under the Apache License, 2.0: http://opensource.org/licenses/apache2.0.php # Licensed to PSF under a Contributor Agreement ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
[Phillip J. Eby] It's not clear to me whether this means that Ian can just relicense his code for me to slap into wsgiref and thence into Python by virtue of my own PSF contribution form and the compatible license, or whether it means Ian has to sign a form too. It's clearly best if Ian signs a form: as http://www.python.org/psf/contrib/ explained, one of the primary aims of the PSF form is to give the PSF legal right to _re_license the work. You have no such right if Ian merely licenses his code to you, and so also no basis on which you can represent that the PSF can relicense the portions of your work derived from Ian's. If Ian can sign a PSF form, that keeps the legalities as clear as possible. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
Phillip J. Eby wrote: At 02:32 PM 4/28/2006 -0500, Ian Bicking 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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py Ian, I see this is under the MIT license. Do you also have a PSF contributor agreement (to license under AFL/ASF)? If not, can you place a copy of this under a compatible license so that I can add this to the version of wsgiref that gets checked into the stdlib? I don't have a contributor agreement. I can change the license in place, or sign an agreement, or whatever; someone should just tell me what to do. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
This explains what to do, and which license to use: http://www.python.org/psf/contrib/ --Guido On 5/22/06, Ian Bicking [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: At 02:32 PM 4/28/2006 -0500, Ian Bicking 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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py Ian, I see this is under the MIT license. Do you also have a PSF contributor agreement (to license under AFL/ASF)? If not, can you place a copy of this under a compatible license so that I can add this to the version of wsgiref that gets checked into the stdlib? I don't have a contributor agreement. I can change the license in place, or sign an agreement, or whatever; someone should just tell me what to do. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
It's not clear to me whether this means that Ian can just relicense his code for me to slap into wsgiref and thence into Python by virtue of my own PSF contribution form and the compatible license, or whether it means Ian has to sign a form too. At 09:25 PM 5/22/2006 -0700, Guido van Rossum wrote: This explains what to do, and which license to use: http://www.python.org/psf/contrib/ --Guido On 5/22/06, Ian Bicking [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: At 02:32 PM 4/28/2006 -0500, Ian Bicking 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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py Ian, I see this is under the MIT license. Do you also have a PSF contributor agreement (to license under AFL/ASF)? If not, can you place a copy of this under a compatible license so that I can add this to the version of wsgiref that gets checked into the stdlib? I don't have a contributor agreement. I can change the license in place, or sign an agreement, or whatever; someone should just tell me what to do. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
It still looks like an application of WSGI, not part of a reference implementation. It seems to me that canonical exemplars are part of what a reference implementation should include. Otherwise it would be a standard implementation, which is considerably different. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
Perhaps this could go in Demo/wsgiref/? Perhaps both Ian's and Phillip's examples could go into Demo/wsgiref/? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 supplement to the PEP, Phillip has written a reference implementation, wsgiref. I don't know how many people have used wsgiref; I'm using it myself for an intranet webserver and am very happy with it. (I'm asking Phillip to post the URL for the current source; searching for it produces multiple repositories.) I believe that it would be a good idea to add wsgiref to the stdlib, after some minor cleanups such as removing the extra blank lines that Phillip puts in his code. Having standard library support will remove the last reason web framework developers might have to resist adopting WSGI, and the resulting standardization will help web framework users. 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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py 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 The motivation there is to give people the basic tools to simple multi-application hosting, and in the process implicitly suggest how other dispatching can be done. I think this is something that doesn't occur to people naturally, and they see it as a flaw in the server (that the server doesn't have a dispatching feature), and the result is either frustration, griping, or bad kludges. By including a basic implementation of WSGI-based dispatching the standard library can lead people in the right direction for more sophisticated dispatching. And prefix dispatching is also quite useful on its own, it's not just educational. Last time this was brought up there were feature requests and discussion on how industrial strength the webserver in wsgiref ought to be but nothing like the flamefest that setuptools caused (no comments please). No one disagreed with the basic premise though, just some questions about the particulars of the server. I think there were at least a couple small suggestions for the wsgiref server; in particular maybe a slight refactoring to make it easier to use with https. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 restrictive (marked with @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py That looks fine to me; I'm not in this business full-time so I'll await others' responses. 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 be added in 2.6? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 be added in 2.6?
I don't think it's frameworky. It could be used to build a very
primitive framework, but even then it's not a particularly useful
starting point.
In Paste this would generally be used below any framework (or above I
guess, depending on which side is up). You'd pass /blog to a blog
app, /cms to a cms app, etc. WSGI already is very specific about what
needs to be done when doing this dispatching (adjusting SCRIPT_NAME and
PATH_INFO), and that's all that the dispatching needs to do.
The applications themselves are written in some framework with internal
notions of URL dispatching, but this doesn't infringe upon those.
(Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but
that's their problem, as the dispatcher is just using what's already
allowed for in the WSGI spec.) It also doesn't overlap with frameworks,
as prefix-based dispatching isn't really that useful in a framework.
The basic implementation is:
class PrefixDispatch(object):
def __init__(self):
self.applications = {}
def add_application(self, prefix, app):
self.applications[prefix] = app
def __call__(self, environ, start_response):
apps = sorted(self.applications.items(),
key=lambda x: -len(x[0]))
path_info = environ.get('PATH_INFO', '')
for prefix, app in apps:
if not path_info.startswith(prefix):
continue
environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
environ['PATH_INFO'] = environ.get('PATH_INFO',
'')[len(prefix):]
return app(environ, start_response)
start_response('404 Not Found', [('Content-type', 'text/html')])
return ['htmlbodyh1Not Found/h1/body/html']
There's a bunch of checks that should take place (most related to /'s),
and the not found response should be configurable (probably as an
application that can be passed in as an argument). But that's most of
what it should do.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 received by web framework makers and users. As a supplement to the PEP, Phillip has written a reference implementation, wsgiref. I don't know how many people have used wsgiref; I'm using it myself for an intranet webserver and am very happy with it. (I'm asking Phillip to post the URL for the current source; searching for it produces multiple repositories.) I believe that it would be a good idea to add wsgiref to the stdlib, after some minor cleanups such as removing the extra blank lines that Phillip puts in his code. Having standard library support will remove the last reason web framework developers might have to resist adopting WSGI, and the resulting standardization will help web framework users. 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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py +1, but lose the unused 'global_conf' parameter and 'make_middleware' functions. 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 I'd rather see something a *lot* simpler - something that just takes a dictionary mapping names to application objects, and parses path segments using wsgiref functions. That way, its usefulness as an example wouldn't be obscured by having too many features. Such a thing would still be quite useful, and would illustrate how to do more sophisticated dispatching. Something more or less like: from wsgiref.util import shift_path_info # usage: #main_app = AppMap(foo=part_one, bar=part_two, ...) class AppMap: def __init__(self, **apps): self.apps = apps def __call__(self, environ, start_response): name = shift_path_info(environ) if name is None: return self.default(environ, start_response) elif name in self.apps: return self.apps[name](environ,start_response) return self.not_found(environ, start_response) def default(self, environ, start_response): self.not_found(environ, start_response) def not_found(self, environ, start_response): # code to generate a 404 response here This should be short enough to highlight the concept, while still providing a few hooks for subclassing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 convince me either. Maybe you can convince Phillip; I'm going to
try to sit on my hands now.
--Guido
On 4/28/06, Ian Bicking [EMAIL PROTECTED] wrote:
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 be added in 2.6?
I don't think it's frameworky. It could be used to build a very
primitive framework, but even then it's not a particularly useful
starting point.
In Paste this would generally be used below any framework (or above I
guess, depending on which side is up). You'd pass /blog to a blog
app, /cms to a cms app, etc. WSGI already is very specific about what
needs to be done when doing this dispatching (adjusting SCRIPT_NAME and
PATH_INFO), and that's all that the dispatching needs to do.
The applications themselves are written in some framework with internal
notions of URL dispatching, but this doesn't infringe upon those.
(Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but
that's their problem, as the dispatcher is just using what's already
allowed for in the WSGI spec.) It also doesn't overlap with frameworks,
as prefix-based dispatching isn't really that useful in a framework.
The basic implementation is:
class PrefixDispatch(object):
def __init__(self):
self.applications = {}
def add_application(self, prefix, app):
self.applications[prefix] = app
def __call__(self, environ, start_response):
apps = sorted(self.applications.items(),
key=lambda x: -len(x[0]))
path_info = environ.get('PATH_INFO', '')
for prefix, app in apps:
if not path_info.startswith(prefix):
continue
environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
environ['PATH_INFO'] = environ.get('PATH_INFO',
'')[len(prefix):]
return app(environ, start_response)
start_response('404 Not Found', [('Content-type', 'text/html')])
return ['htmlbodyh1Not Found/h1/body/html']
There's a bunch of checks that should take place (most related to /'s),
and the not found response should be configurable (probably as an
application that can be passed in as an argument). But that's most of
what it should do.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 super-simple implementation that emphasizes the concept, not feature-richness. A simple dict-based implementation showcases both the wsgiref function for path shifting, and the idea of composing an application out of mini-applications. (The point is to demonstrate how people can compose WSGI applications *without* needing a framework.) But I don't think that this demo should be a prefix mapper; people doing more sophisticated routing can use Paste or Routes. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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. I'm for doing what you think is best. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
On 4/28/06, Phillip J. Eby [EMAIL PROTECTED] 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 take care of. I'm fine with a super-simple implementation that emphasizes the concept, not feature-richness. A simple dict-based implementation showcases both the wsgiref function for path shifting, and the idea of composing an application out of mini-applications. (The point is to demonstrate how people can compose WSGI applications *without* needing a framework.) But I don't think that this demo should be a prefix mapper; people doing more sophisticated routing can use Paste or Routes. 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. Perhaps this could go in Demo/wsgiref/? Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py +1, but lose the unused 'global_conf' parameter and 'make_middleware' functions. Yeah, those are just related to Paste Deploy and wouldn't go in. 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 I'd rather see something a *lot* simpler - something that just takes a dictionary mapping names to application objects, and parses path segments using wsgiref functions. That way, its usefulness as an example wouldn't be obscured by having too many features. Such a thing would still be quite useful, and would illustrate how to do more sophisticated dispatching. Something more or less like: from wsgiref.util import shift_path_info # usage: #main_app = AppMap(foo=part_one, bar=part_two, ...) class AppMap: def __init__(self, **apps): self.apps = apps def __call__(self, environ, start_response): name = shift_path_info(environ) if name is None: return self.default(environ, start_response) elif name in self.apps: return self.apps[name](environ,start_response) return self.not_found(environ, start_response) def default(self, environ, start_response): self.not_found(environ, start_response) def not_found(self, environ, start_response): # code to generate a 404 response here This should be short enough to highlight the concept, while still providing a few hooks for subclassing. That's mostly what I was thinking, though using a full prefix (instead of just a single path segment), and the default is the application at '', like in my other email. paste.urlmap has several features I wouldn't propose (like domain and port matching, more Paste Deploy stuff, and a proxy object that I should probably just delete); I probably should have been more specific. URLMap's dictionary interface isn't that useful either. Another feature that the example in my other email doesn't have is / handling, specifically redirecting /something-that-matches to /something-that-matches/ (something Apache's Alias doesn't do but should). Host and port matching is pretty easy to do at the same time, and in my experience can be useful to do at the same time, but I don't really care if that feature goes in. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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
take care of.
I'm fine with a super-simple implementation that emphasizes the concept,
not feature-richness. A simple dict-based implementation showcases both
the wsgiref function for path shifting, and the idea of composing an
application out of mini-applications. (The point is to demonstrate how
people can compose WSGI applications *without* needing a framework.)
But I don't think that this demo should be a prefix mapper; people doing
more sophisticated routing can use Paste or Routes.
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 call sophisticated. The default
application handling in particular means that AppMap isn't really useful
without subclassing or assigning to .default.
Prefix matching wouldn't show off anything else in wsgiref, because
there's nothing else to use; paste.urlmap doesn't use any other part of
Paste either (except one unimportant exception) because there's just no
need.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 call sophisticated. The default
application handling in particular means that AppMap isn't really useful
without subclassing or assigning to .default.
Prefix matching wouldn't show off anything else in wsgiref,
Right, that would be taking away one of the main reasons to include it.
To make the real dispatcher, I'd flesh out what I wrote a little bit, to
handle the default method in a more meaningful way, including the
redirect. All that should only add a few lines, however.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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
barely more complex and not what I'd call sophisticated. The default
application handling in particular means that AppMap isn't really useful
without subclassing or assigning to .default.
Prefix matching wouldn't show off anything else in wsgiref,
Right, that would be taking away one of the main reasons to include it.
That's putting the cart in front of the horse, using a matching
algorithm because that's what shift_path_info does, not because it's the
most natural or useful way to do the match.
I suggest prefix matching not because it shows how the current functions
in wsgiref work, but because it shows a pattern of dispatching WSGI
applications on a level that is typically (but for WSGI, unnecessarily)
built into the server. The educational value is in the pattern, not in
the implementation.
If you want to show how the functions in wsgiref work, then that belongs
in documentation. Which would be good too, people like examples, and
the more examples in the wsgiref docs the better. People are much less
likely to see examples in the code itself.
To make the real dispatcher, I'd flesh out what I wrote a little bit, to
handle the default method in a more meaningful way, including the
redirect. All that should only add a few lines, however.
It will still be only a couple lines less than prefix matching.
Another issue with your implementation is the use of keyword arguments
for the path mappings, even though path mappings have no association
with keyword arguments or valid Python identifiers.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 dispatch /foo/bar, why not just use: AppMap(foo=AppMap(bar=whatever)) So, I don't see prefix matching as introducing anything that's worth the extra complexity. If somebody needs a high-performance prefix matcher, they can get yours from Paste. If I was going to include a more sophisticated dispatcher, I'd add an ordered regular expression dispatcher, since that would support use cases that the simple or prefix dispatchers would not, but it would also support the prefix cases without nesting. Another issue with your implementation is the use of keyword arguments for the path mappings, even though path mappings have no association with keyword arguments or valid Python identifiers. That was for brevity; it should probably also take a mapping argument. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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)
--
Traceback (most recent call last):
File /disk/u/t/dev/misc/wsgiref/src/wsgiref/tests/test_handlers.py,
line 205, in testHeaderFormats
(stdpat%(version,sw), h.stdout.getvalue())
AssertionError: ('HTTP/1.0 200 OK\\r\\nDate: \\w{3} \\w{3} [ 0123]\\d
\\d\\d:\\d\\d:\\d\\d \\d{4}\\r\\nServer: FooBar/1.0\r\nContent-Length:
0\\r\\n\\r\\n', 'HTTP/1.0 200 OK\r\nDate: Fri, 28 Apr 2006 23:28:11
GMT\r\nServer: FooBar/1.0\r\nContent-Length: 0\r\n\r\n')
--
This is probably due to Guido's patch to make the Date: header more RFC
compliant. I'll take a look at it this weekend.
On a separate note, what are you actually proposing to include? It'd be
good to remove the TODO list, for example, unless those are things To Be
Done before adding it into Python 2.5.
Well, it looks like the validate bit will be going in, and we're talking
about what to put in router, so that'll take care of half the list right
there. :)
The other two items can wait, unless somebody wants to contribute them.
Will it be added as 'wsgi' or 'wsgiref?
I assumed it would be wsgiref, which would allow compatibility with
existing code that uses it.
I'd also personally suggest putting anything intended for common use
directly under the top level, i.e.
wsgiref.WSGIServer
vs
wsgiref.simple_server.WSGIServer
I'm against this, because it would force the handlers and simple_server
modules to be imported, even for programs not using them.
And, finally, is there any documentation?
Only the docstrings. Contributions are more than welcome.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
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 of new features. I just don't understand this. It's not more complex. Prefix matching works like: get the prefixes order them longest first check each one against PATH_INFO use the matched app or call the not found handler Name matching works like: get the mapping get the next chunk get the app associated with that chunk use that app or call the not found handler One is not more complex than the other. If I want to dispatch /foo/bar, why not just use: AppMap(foo=AppMap(bar=whatever)) You create an intermediate application with no particular purpose. You get two default handlers, two not found handlers, and you create an object tree that is distracting because it is artificial. Paths are strings, not trees or objects. When you confuse strings for objects you are moving into framework territory. If I was going to include a more sophisticated dispatcher, I'd add an ordered regular expression dispatcher, since that would support use cases that the simple or prefix dispatchers would not, but it would also support the prefix cases without nesting. That is significantly more complex, because SCRIPT_NAME/PATH_INFO cannot be used to express what the regular expression matched. It also overlaps with frameworks. WSGI doesn't offer any standard mechanism to do that sort of thing. It could (e.g., a wsgi.path_vars key), but it doesn't. Or you do something that looks like mod_rewrite, but no one wants that. Prefix based routing represents a real cusp -- more than that, and you have to invent conventions not already present in the WSGI spec, and you overlap with frameworks. Less than that... well, you can't do a whole lot less than that. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
