I think CherryPy's WSGI server should go in: it's stable, and the best-performing WSGI HTTP server out there.Peter
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options
At 04:20 PM 2/4/2006 -0800, Guido van Rossum wrote:
>ISTM that wsgiref itself
>is stable enough, and having it in the stdlib would lower the bar for
>anybody to develop WSGI-compliant apps even if they refuse to use a
>toolkit. A lot of the other things you're mentioning above seem to be
>of a diff
Guido van Rossum wrote:
>>I think a WSGI-based HTTP server is fairly easy to stabalize. Clark
>>Evans contributed a server based on SimpleHTTPServer, which I think is
>>both pretty complete and doesn't do anything besides HTTP serving (e.g.,
>>no static file serving):
>>http://svn.pythonpaste.org/
> >I am probably missing something, but shouldn't there also be an API to
> >render the template to a string or stream given some context of
> >variable names? I'm looking at this from a very different perspective,
> >namely *using* various templating engines from an app that otherwise
> >doesn't u
On 2/4/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> >> Perhaps wsgiref
> >>should go into the Python 2.5 standard library?)
> >
> > Sure. I'd suggest that we might want to expand it a little to include some
> > of the fine contributions of other authors, such as Ian's "lint
On Feb 4, 2006, at 6:07 PM, Ian Bicking wrote:
>
I thought the entire point of the development of a better packaging
system (eggs) is so that not everything needs to go into the standard
library.
James
___
Web-SIG mailing list
Web-SIG@python.org
We
Well, here's the proposal I had before, tweaked slightly. This is
mostly like the TG/Buffet API, but with find_resource extracted. I
realize this is the basis of the whole WSGI offshoot before, and maybe
an API without that would be useful or easier to implement. But it
would also be way mor
Phillip J. Eby wrote:
>> Perhaps wsgiref
>>should go into the Python 2.5 standard library?)
>
>
> Sure. I'd suggest that we might want to expand it a little to include some
> of the fine contributions of other authors, such as Ian's "lint" middleware
> (which sits between an app and a server a
At 11:37 AM 2/4/2006 -0800, Ben Bangert wrote:
>I think the main reason Ian suggested it was because he wanted to
>implement his own lookup scheme to find templates. As I mentioned
>above, this begins to take us to the internals so I'm inclined to
>agree that its not going to help here.
Actual
On Feb 4, 2006, at 10:55 AM, Phillip J. Eby wrote:
> But that's the case that threw this whole thing off track to begin
> with, because you can only pass in a find_template if *you're the
> template manager*. In the interface we're currently discussing,
> finding templates is internal to th
At 09:31 AM 2/4/2006 -0800, Ben Bangert wrote:
>On Feb 3, 2006, at 7:40 PM, Phillip J. Eby wrote:
>>But it seems a little ugly to me to cram another key into environ
>>to tell the manager what template to use, when you could just have
>>a 'get(template_id)' call that gets you the WSGI app to use.
At 08:17 AM 2/4/2006 -0800, Guido van Rossum wrote:
>[Phillip]
> > API to be provided by a "template engine":
> >
> > compile_string(text), compile_stream(input_stream) - return a WSGI
> > application object for the template described by the text or file-like
> object
> >
> > write_compiled(app, o
On Feb 4, 2006, at 8:17 AM, Guido van Rossum wrote:
> I am probably missing something, but shouldn't there also be an API to
> render the template to a string or stream given some context of
> variable names? I'm looking at this from a very different perspective,
> namely *using* various templatin
On Feb 3, 2006, at 7:40 PM, Phillip J. Eby wrote:
> The problem for me is, I was hoping we would end up defining a
> manager->compiler interface and a publisher->resource interface
> rather than a publisher->manager one. Then again, maybe we should
> define both, and let people plug things
[Phillip]
> API to be provided by a "template engine":
>
> compile_string(text), compile_stream(input_stream) - return a WSGI
> application object for the template described by the text or file-like object
>
> write_compiled(app, output_stream) - save the compiled form of the template
> to output_s
15 matches
Mail list logo
