riable names? I'm looking at this from a very different perspective,
namely *using* various templating engines from an app that otherwise
doesn't use a framework but still needs templating.
(PS having tried WSGI a bit now I'm fine with it. Perhaps wsgiref
should go into the Python 2.
g above seem to be
of a different kind -- nice-to-haves, for sure, but either they're not
100% stable yet, or they enter the slippery slope of appearing to be a
specific framework choice (cgitb already has that feel to me).
> If stuff was put into the standard library, I thin
lso nonexistent at the
> moment. I'd be happy to co-ordinate and consolidate the additions, and of
> course I'll write documentation, though any assistance people can offer
> would be greatly appreciated. Some people have writ
ver.py. (It does in a sense apply
to SimpleHTTPServer.py since that serves up the current directory.)
Thanks for correctly channeling the sentiment behind the standard
library server hierarchy!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
a of course was to allow existing framework APIs to wrap WSGI, so
> that you can have request.path or REQUEST.path_info or whatever suits your
> fancy. It was never intended that anybody but framework developers write
> "bare metal" WSGI code, and such developers have to touch ei
On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I suspect most templates will buffer their output internally, unless
> somehow configured or dynamically set not to do so.
Why would they? Isn't that a function that the web server typically does?
--
--Guido van Rossum
gt; Ben and Michael have both pointed out that trying to meet a spec that calls
> for them to change how their inner find_template works would be costly.
I can't parse this because I don't know what relationship Ben and
Michael have with the systems mentioned.
--
--Guido van Rossum (h
the standard library and
production quality pretty much mutually exclusive requirements (except
for the obvious correctness requirements, which are only a tiny
fraction of the set of properties going into production quality).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
notice at the top saying """This is both an example
> of how WSGI can be implemented, and a basis for running simple web
> applications on a local machine, such as might be done when testing or
> debugging an application. It has not been
cting much maintenance.
But if a maintainer is all that's needed to make everybody happy, I'd
be happy to volunteer if no-one else does.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@
On 2/14/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Make everybody *happy*? Now *that*'s wishful thinking. ;) I usually
> settle for "doesn't annoy anybody enough to cause a fork."
Oh, I'll gladly make them fork. Good riddance. :-)
--
--Guido van Ros
y* consecutive blank lines here and there.
What are these for?)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.o
mon, it's easy to forget which import
style was used and to use the wrong invocation style. While the error
doesn't pass silently, it's annoying and a bit jarring; the error
message isn't all that clear.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
ical* reason -- server-side SSL use probably
requires a lot more OpenSSL APIs to be exposed. Also, managing an SSL
server *securely* requires much care. So perhaps having to use an
external library (pyopenssl or m2crypto) could be appropriate. But
it's nothing fundamental.
--
--Guido van Rossum
On 2/14/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 13, 2006 at 12:49:00PM -0800, Guido van Rossum wrote:
> | There are many different ways to judge "production quality". If we're
> | talking about correct, (standards-compliant, even) code, I wholl
On 2/15/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 15, 2006 at 10:26:41AM -0800, Guido van Rossum wrote:
> | So we disagree fundamentally -- IMO sometimes a toy is right for the
> | standard library
>
> I'm seriously surprised to hear this. What other st
004-September/000764.html
>
> Adding status code constants to httplib
> http://mail.python.org/pipermail/web-sig/2004-September/000842.html
+1. Feel free to submit a patch to SF and assign it to me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
's slowly decohering/kipplizing.
> >
> > Maybe we need a PEP, so that we can all discuss the subject
> > (rationally ;-) and sort out all of the issues before we go ahead and
> > commit anything?
>
> Great idea! That's exactly what I thought when I orga
uss the particulars.
> | Is there a code path in one or more of these servers which you think is
> | unneeded and problematic?
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
D]>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.o
risks of adding wsgiref to the stdlib";
not "what could we think of that's even better". Achieving a perfect
decision is not the goal; having general consensus that adding it
would be better than not adding is would be good. Pointing out
specific bugs in wsgiref and suggestin
eful 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
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,
> >
path_info()' in
> wsgiref.util.
I'm for doing what you think is best.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
htt
application into a service with its own port, etc, etc.
>
> Thanks for any pointers,
> Paul.
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mai
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/)
___
Web-SIG maili
gt;
>
> --
> 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.
security fix I would strongly
recommend not to remove it and to change the WSGI spec instead.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
U
On 12/20/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:06 PM 12/20/2006 -0800, Guido van Rossum wrote:
> >On 12/20/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 10:12 AM 12/20/2006 -0800, Guido van Rossum wrote:
> >> >We're
might want to pass that information back to the CherryPy developers,
> although I think there are probably some reading this list.
>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
>
21/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
>
>
>
> Guido van Rossum wrote:
> > We decided to add chunking encoding to our own server,
> > it wasn't all that hard. What's the business of only
> > doing it for certain status codes?
>
> Less o
self. Phillip promised he would clean it up
for distribution but never did, so the version distributed with Python
2.5 has a few strange ideosyncracies that I'm afraid to clean up
because last time someone touched Phillip's code he threw a fit.)
--
--
7;s often easier to code than to reuse!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
On 12/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:55 AM 12/22/2006 -0800, Guido van Rossum wrote:
> >(Also, wsgiref violates a couple of Python style guides that make me
> >not want to update it myself. Phillip promised he would clean it up
> >for distri
licensing issue?
> Or is it quality assurance?
I think I'm done discussing Google internals.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
name. This is by design, I
assume -- check out the snippet for the first Google hit for "Zope".
Paste (despite its Google snippet) historically seems to fall in the
same category and it may be tough to undo this; moving the install
functionality to a separate brand name might b
ublic (or
relative outsiders like myself) will have instinctive responses to
these things that are hard to change.
PS. Where do people meet for drinks in the Reval Hotel in Vilnius tonight?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
chance of a summary that's not a
tutorial nor a reference?
> WebOb has a lot more methods and attributes than other libraries, but
> this document points out only things where there are differing names or
> things not in WebOb. Most other such objects also don't have the same
>
Thanks! I stand educated.
2007/10/22, Jacob Smullyan <[EMAIL PROTECTED]>:
> On Mon, Oct 22, 2007 at 10:01:52AM -0700, Guido van Rossum wrote:
> > 2007/8/15, Ian Bicking <[EMAIL PROTECTED]>:
> > I may be totally behind the times here, but I've always found it odd
utorial nor a reference?
>
> Did you look at the file serving example?
> http://pythonpaste.org/webob/file-example.html
Thatr's the first thing I looked at, and that prompted my comments above. :-)
> I suppose a quick summary would a
ch seem better
suited for an advanced manual.
I suggest the wiki-in-one-page would be a better example, even if you
consider it too common (serving static files isn't common? :-).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Py3k, it returns a bytes instance: b'\xe1\x88\xb4'.
The issue applies to input as well as output -- data read from a
socket is also represented as bytes, unless you're using makefile()
with a text mode and an encoding.
You might want to look at how the unittests for wsgiref
On Dec 6, 2007 5:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:27 PM 12/6/2007 -0800, Guido van Rossum wrote:
> >You might want to look at how the unittests for wsgiref manage to pass
> >in Py3k though. ;-)
>
> Unless they've been changed, I'
zzy on some of the
> details there.
>
> The actual response body should also be bytes. Unless again we want to
> introduce upstream encoding.
>
> This does make everything feel more complicated.
It's the same level of complexity you run into as soon as you want to
handle Unic
ython encoding to yield usable char*
> string for output.
The encoding can/must be specified per text stream.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/s
On Dec 9, 2007 7:56 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 12:37 AM, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> > > On 08/12/2007, Phillip J. Eby <[EMAIL PROTECTE
to give
even worse results than expecting the language developers always to
know how library modules are being used.
And if you want to help, please join the stdlib-sig, rather than
whining off-line!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
ID: 19017044
<http://www.dartworks.biz/>
=
___
Baypiggies mailing list
[EMAIL PROTECTED]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/b
to tell them apart in
> the package since they both use the same name for the classes they
> contain.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.o
Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
__
ed to adapt them.
>
> Yes, that would help people using Python 2.x, but would WSGI 1.0 even
> be available in Python 3.0 given your plan?
>
> Regards,
>
> Martijn
>
>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
; > I would definitely support the incusion of a JSON library in the
> > standard lib. And, I think that it should be simplejson which is
> > used by TurboGears, Pylons, and bundled with Django.
>
> +1
+1 here too.
Brett should probably figure out where to pu
so should
> play a bigger role in any such decision than mere benchmark speed.
Well, so fix this. How hard can it be?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.pyt
debate without much benefit.
> As far as Jython support goes, I suppose that's probably fixable
> without too much effort. I would imagine that the problems are just in
> the decoder, because of the sre_* module (ab)use. Was there some other
> reason for writing a Jython-specifi
omplicate the cgi module needlessly if
> we can instead use unicode for those 3 environ entries. I'll report back
> here.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG:
On Wed, Apr 1, 2009 at 12:15 PM, Ian Bicking wrote:
> On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum wrote:
>> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer wrote:
>>> Good timing. We had been thinking to make everything strings except for
>>> SCRIPT_NAME, PATH_IN
On Wed, Apr 1, 2009 at 3:37 PM, P.J. Eby wrote:
> At 01:09 PM 4/1/2009 -0700, Guido van Rossum wrote:
>>
>> Well you could make the bytes versions available under different keys.
>> I think you do something a bit similar this in webob, e.g. req.params
>> vs. req.str
optimal solution --
AFAICT there is no agreement on what that solution would be, if one
weren't to take porting Python 2 code into account). IOW
something/sokebody has gotta give.
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG maili
l was to have one
>> supersede the other, as is also the case here.
>>
>
> _______
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web
specs give the implementers of
the spec some leeway in how to conform to the spec (otherwise it
wouldn't be a spec but a program :-). Doubly so when there are two
sides to a protocol (e.g. client/server, consumer/producer).
--
--Guido van Rossum (python.org/~guido)
___
__
> Python-Dev mailing list
> python-...@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 (python.org/~guido)
___
On Sat, Sep 25, 2010 at 7:00 PM, P.J. Eby wrote:
> At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote:
>>
>> This is a very laudable initiative and I approve of the changes -- but
>> I really think it ought to be a separate PEP rather than pretending it
>> is just a se
tus for the
*original* PEP 333 and I'm happy to approve a new PEP which includes
PJE's corrections. I'm not going to approve Final status for a
history-rewrite of PEP 333.
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG mailing list
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw wrote:
> On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
>
>> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
>>> I'm happy approving Final status for the
>>> *original* PEP 333 and I'm happy to ap
similar note at the top of PEP -- maybe mark up the
differences in PEP so people can easily tell what was added. And
move PEP 333 to Final status.
--Guido
On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby wrote:
> At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
>>
>> On Sun,
rather
>> just withdraw it and let someone else resubmit it (or something like it)
>> later if they want. It's just going to cause confusion if it's left in
>> a zombie state without a champion.
>
> Ah, but Deferred is an official state, and describes quite c
ce you have in the past posted here suggesting you are
interested in carrying PEP 444 / WSGI 2.0 forward, please acknowledge
that you understand the concerns raised in this thread.
Graham, I suggest that you don't worry about this issue, and instead
focus on helping the draft turn into a standard
forward should be different, please write me off-list with your concerns.)
Everyone else on this list, please make a new year's resolution to help the
WSGI 2.0 standard become a reality in 2011.
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
On Sun, Jan 2, 2011 at 11:14 AM, Chris McDonough wrote:
> On Sun, 2011-01-02 at 09:21 -0800, Guido van Rossum wrote:
> > Graham, I hope that you can stop being grumpy about the process that
> > is being followed and start using your passion to write up a critique
> > of th
cessary, until we
>>> reach some sort of technical impasse it doesn't address.
>>>
>>
> Async is one area that does not cover, and that by not having a
> standard which incorporates async means competing, incompatible solutions
> have been created.
&g
On Sun, Jan 2, 2011 at 12:14 PM, Alice Bevan–McGregor
wrote:
> On 2011-01-02 09:21:29 -0800, Guido van Rossum said:
>
>> Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT
>> it's this: https://github.com/GothAlice/wsgi2/blob/master/pep444.
efully you can write down your
ideas for all to see? Perhaps you have an implementation too? Maybe seeing a
concrete proposal will help us all see how big or small of a shoehorn will
be needed.
(Just trying to keep this thread from degenerating into a shouting match.)
--
--Guido van Rossum (pyth
On Sun, Jan 2, 2011 at 7:08 PM, Tres Seaver wrote:
> On 01/02/2011 04:31 PM, Guido van Rossum wrote:
>> On Sun, Jan 2, 2011 at 12:55 PM, Masklinn wrote:
>>
>>> On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote:
>>>> On 2011-01-02 11:14:00 -0800, Chris M
On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss wrote:
> On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum wrote:
>> Although [PEP ] is still marked as draft, I personally think of it
>> as accepted; [...]
>
> What does it take to get PEP formally marked as
y around the time you were writing the above). If somebody can
> point me to the proper Py3 incantation for writing bytes to stdout, I'll fix
> the one remaining TODO marker as well.
Would
sys.stdout.buffer.write(b'abc')
do?
(If you mix this with writing strings to sys.std
t of specification (no matter
how bad it is) and still call the resulting spec WSGI 1.0(.x) -- we
don't want to rule out WSGI 1.0 compliance of apps or frameworks that
would be considered compliant under the original 1.0 spec.
--
--Guido van Rossum (python.org/~guido)
__
On Tue, Jan 4, 2011 at 7:48 AM, P.J. Eby wrote:
> At 06:30 PM 1/3/2011 -0800, Guido van Rossum wrote:
>>
>> Would
>>
>> sys.stdout.buffer.write(b'abc')
>>
>> do?
>>
>> (If you mix this with writing strings to sys.stdout directly, you m
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
e 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 dropping CGI in
ince has been answered with, "well, the use case is that you want it to be
> async."
>
> Only, that's a *server* developer's use case, not an app developer's use
> case... and only for a minority of server developers, at that.
>
> ___
27;ve checked in the two-line change to
>> add .buffer in. ;-)
>
> So does that mean PEP can be accepted now?
TBH I've totally lost track. Hopefully PJE and Graham can tell you...
--
--Guido van Rossum (python.org/~guido)
___
one to date has been experiments to test changes
> to other aspects of WSGI. ;-)
That translation works.
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
__
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG mailing list
Web-
> Python 2 ones. ;-)
>
> Latest CGI/WSGI bridge example extract from PEP seems to work
> okay for my simple test.
>
> So, if no more technical problems (vs cosmetic) that anyone else sees,
> that is probably it and and we can toss this baby out the door.
>
> Graham
&
On Wed, Jan 12, 2011 at 2:34 PM, Alice Bevan–McGregor
wrote:
> On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
>>
>> Ok, now that we've had a week of back and forth about this, let me repeat
>> my "threat". Unless more concerns are brought up in the next 2
dded as an afterthought to WSGI about nine years
>> ago, and we didn't get it right, but it long ago was too late to do
>> anything about it. A properly async WSGI implementation will probably
>> have to wait for Tulip (Guido's project to bring a standard async
>> prog
ting PEP 3156 into WSGI? Though it may have to
>> be named WSGI 2.0 to emphasize that it is backwards incompatible.
>>
>>
> I have an idea already,
> I'll write an initial implementation based on tulip.http.Response &
> tulip.http.ServerHttpProtocol and I'll write
p by GMail?
--
--Guido van Rossum (python.org/~guido)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Wow. May I suggest asking for some new moderators? I understand the need to
moderate posts (to prevent spam) but this isn't exactly encouraging to new
contributors to the community...
On Mon, Sep 15, 2014 at 10:47 AM, Bill Janssen wrote:
> Guido van Rossum wrote:
>
> >
a bit similar - but less horrible - to JSON unserializing;
> since then, the problem was solved in a different way by adding a
> framing layer to pickle protocol 4 :-).
>
> Regards
>
> Antoine.
>
>
> ___________
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: h
Anyway, I think I'm getting ahead of myself, but I do think it would be
nice if the next WSGI standard supported asyncio. For older Python versions
it could then instead support Trollius (
https://pypi.python.org/pypi/trollius), a backport of a
91 matches
Mail list logo
