Re: [Web-SIG] Future of WSGI

On Nov 24, 2009, at 10:16 PM, Sylvain Hellegouarch wrote: Though it shouldn't be considered as a problem, the fact that probably no existing framework actually use the raw dictionary (there is, in almost all cases, a wrapping into a friendlier object), one might wonder why keeping such a lo

[Web-SIG] wsgi and generators (was Re: WSGI and start_response)

On Thu, 8 Apr 2010, P.J. Eby wrote: This is also a good time for people to learn that generators are usually a *very bad* way to write WSGI apps - yielding is for server push or sending blocks of large files, not tiny strings. In general, if you're yielding more than one block, you're almost

Re: [Web-SIG] WSGI for Python 3

going to come with costs, but as things have dragged on, the lack of choice thus far is starting to have as much of a cost as the costs that are wanting to be resolved. [1] I not expecting or hoping for porting/migrating to Python 3 to be simple/automatic/easy, but perhaps I'm cruel. -- Chris

Re: [Web-SIG] PEP 444 (aka Web3)

and other flim flammery. In other words it is good that the units are basic and fundamental. -- Chris Dent http://burningchrome.com/ [...] ___ Web-SIG mailing list Web-SIG@python.org We

Re: [Web-SIG] PEP 444 (aka Web3)

y wrong, but it works rather nicely. -- Chris Dent http://burningchrome.com/ [...] ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Uns

Re: [Web-SIG] PEP 444 (aka Web3)

r is suggested as perhaps a best practice. Those sorts of things belong in communication that is out of band of the spec. -- Chris Dent http://burningchrome.com/ [...] ___ Web-SIG mailing li

Re: [Web-SIG] PEP 444 / WSGI 2 Async

biases) middleware turns it into UTF-8 on the way out. I've naively never understood why you want do anything else? My general rule is unicode inside, UTF-8 at the boundaries. That's all I got so far. I applaud you for taking on this challenge. It's work that needs to

Re: [Web-SIG] PEP 444 / WSGI 2 Async

tandard would not be seen and taken into consideration when developers are writing what they will think /must/ be middleware. Yeah, so? :) See my post from a few minutes ago which covers this. Yay! -- Chris Dent

Re: [Web-SIG] PEP 444 Goals

think working from a list of goals is an excellent way to make some headway. -- Chris Dent http://burningchrome.com/ [...]___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.py

Re: [Web-SIG] Server-side async API implementation sketches

ler generates (sends out in chunks) the web page from those strings. So, this is me saying: I'm in favor of a post-wsgi1 world where apps are encouraged to be generators. To me they are just as useful in sync and async contexts. -- Chris Dent

[Web-SIG] resources for porting wsgi apps from python 2 to 3

otes on this project at http://tiddlyweb3.tiddlyspace.com/ [4] Which is what it should have been all along? -- Chris Dent http://peermore.com/ -- Chris Dent http://burningchrome.com/ [...] __

Re: [Web-SIG] resources for porting wsgi apps from python 2 to 3

ps request and http.client, but I'm close. -- Chris Dent http://burningchrome.com/ [...] ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Uns

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

as something other than primitives. Thanks for getting this ball rolling, again. It can be challenging when it has been visited so many times. I think making a clean break to create something new, while still acknowledging the continue

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

I want from a light rev of WSGI is not to have to jump through those hoops. It may be that's not feasible but I reckon we're at the wishing stage of the discussion. -- Chris Dent

Re: [Web-SIG] Inviting feedback on my proposed "ASGI" spec

nted to raise that point about multiple headers. As you were. Carry on. etc. -- Chris Dent http://burningchrome.com/ [...] ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.p