Re: [Web-SIG] PEP 444 != WSGI 2.0
At 05:04 PM 1/2/2011 +1100, Graham Dumpleton wrote: That PEP was rejected in the end and was replaced with PEP 342 which worked quite differently, yet I cant see that the WSGI specification was revisited in light of how it ended up being implemented and the implications of that. Part of my contribution to PEP 342 was ensuring that it was sufficiently PEP 325-compatible to ensure that PEP 333 wouldn't *need* revisiting. At least, not with respect to generator close() methods anyway. ;-) ___ 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
Re: [Web-SIG] PEP 444 != WSGI 2.0
Alice and Graham, I worry a lot that there's a fight brewing here that will lead to disappointment all around. I see accusations, demands, and passion. I also see a lot of apathy in the web-sig. This is not a recipe for a successful standard. Since it appears we have or are about to face a breakdown of communication, I'd like to start with some remarks on the mechanics of communication. - 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.textile. I find it a bit disturbing that the official copy of PEP 444 ( http://www.python.org/dev/peps/pep-0444/ ) hasn't been updated. This is confusing for occasional observers (like myself), since the python.orgcopy looks quite dead. It also is not in line with the PEP workflow as written down in PEP 1 ( http://www.python.org/dev/peps/pep-0001/#pep-work-flow ). - It is not reasonable to demand a discussion on IRC. In fact I think it is one of the worst media for arriving agreement over a standard. IRC doesn't have public logs for those who didn't participate in real time (apparently intentionally so); it is pretty hostile to people who don't use it regularly (I am one of those); it doesn't work well for people in different timezones. Blog comments are not much better (they are archived, but as a medium they get too much spam and are too scattered to be worth tracking down for other participants); the web-sig mailing list is the preferred forum. - If you are going to quote stuff from earlier in the thread and respond to it using you, please don't strip the attributions (or add them if your mailer doesn't). Also it's best to keep the person you address in the To: line of the message (or add them back if your mailer doesn't automatically do this). With that out of the way, let me try to analyze the crux of the matter. The WSGI 1.0 standard (PEP 333) has been widely successful, but, like any standard, it has some flaws. People thought that Python 3 would be a good opportunity to fix the flaws. A proposal was drafted, and posted as PEP 444, but no agreement was reached. In order to fix some obvious flaws due to Python 3's different treatment of bytes and text, a much less ambitious update was produced as PEP , and labeled WSGI 1.0.1. Although this is still marked as draft, I personally think of it as accepted; it is really just a very small set of clarifications and disambiguations of PEP 333, specifically for the benefit of interoperability between WSGI 1.0 apps and servers across the Python 2 / Python 3 boundary. But there still was no WSGI 2.0, and the original PEP 444 authors stopped pushing for their more ambitious draft (I recall this from the web-sig list; the PEP itself was not updated to reflect this). Then Alice came along, with much enthusiasm (though perhaps not enough prior understanding of Python's PEP process) and offered to rewrite PEP 444 to make it better, and to aim to make the updated version the agreed-upon WSGI 2.0 standard. I can't quite tell what happened from there; IIRC Alice's proposal did not receive much objection but neither did she get much support from the folks on web-sig -- perhaps people were tired of the discussion (which had already gone around once and not reached any agreement), perhaps people were too busy to read the list. It seems Graham, at least, falls in the latter category and is now regretting that he didn't speak up earlier. Ian, OTOH, seems to implicitly endorse Alice's actions, and seems to be hoping that a widely accepted WSGI 2.0 standard will come out of her work. In the mean time, Alice (understandably) has looked for other forums where she got more feedback -- I may not like IRC, but I can see how the general apathy on the web-sig is not exactly encouraging. (This is a general problem with Python -- we always complain that there aren't enough people to do the work, but when someone shows up and offers to do some work, they don't get much support. On python-dev we've acknowledged this and are trying to get better about it.) In order to get WSGI 2.0 back on the standards track, I think a number of things have to happen. First, it would be great if Alice could prepare a version of her draft in the format required for PEPs, and submit it to the PEP editors ( p...@python.org). Note that the PEP editors do *not* judge a PEP by its technical merits or have a say in its approval (though they may reject outright nonsense) -- they merely facilitate the discussion by promptly checking in the submitted draft, so that PEP authors don't need SVN (or, soon, I hope Hg) access. The PEP editors also ensure that the PEP is formatted right, so that it can be automatically processed into HTML for publication on python.org, and they may make simple fixes for typos/spelling/grammar. In my experience (being one of them), the PEP editors usually respond within 24 hours, and don't have
Re: [Web-SIG] PEP 444 != WSGI 2.0
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 the technical merits of Alice's draft. You don't have to attack the whole draft at once -- you can start by picking one or two important issues and try to guide a discussion here on web-sig to tease out the best solutions. Please understand that given the many different ways people use and implement WSGI there may be no perfect solution within reach -- writing a successful standard is the art of the compromise. (If you still think the process going 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. I think Graham mostly has an issue with this thing being called WSGI 2. FTR, avoiding naming arguments is why I titled the original PEP Web3. I knew that if I didn't (even though personally I couldn't care less if it was called Buick or McNugget), people would expend effort arguing about the name rather than concentrate on the process of creating a new standard. They did anyway of course; many people argued publically wishing to rename Web3 to WSGI2. On balance, though, I think giving the standard a neutral name before it's widely accepted as a WSGI successor was (and still is) a good idea, if only as a conflict avoidance strategy. ;-) That said, I have no opinion on the technical merits of the new PEP 444 draft; I've resigned myself to using derivatives of PEP forever. It's good enough. Most of the really interesting stuff seems to happen at higher levels anyway, and the benefit of a new standard doesn't outweigh the angst caused by trying to reach another compromise. I'd suggest we just embrace it, adding minor tweaks as necessary, until we reach some sort of technical impasse it doesn't address. - C ___ 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
Re: [Web-SIG] PEP 444 != WSGI 2.0
On Sun, Jan 2, 2011 at 12:14 PM, Alice Bevan–McGregor al...@gothcandy.comwrote: 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.textile. I find it a bit disturbing that the official copy of PEP 444 ( http://www.python.org/dev/peps/pep-0444/ ) hasn't been updated. This is confusing for occasional observers (like myself), since the python.orgcopy looks quite dead. It also is not in line with the PEP workflow as written down in PEP 1 ( http://www.python.org/dev/peps/pep-0001/#pep-work-flow ). I am unsure of the policy behind updating a PEP on the website from a partial (with glaring holes) source. In my rewrite there are several sections that need to be fleshed out before I would consider pushing it up-stream. I'm tentative that way. ;) Please drop the perfectionism. It is unpythonic. :) We believe in release early, release often here. Even if *you* believe there are no glaring holes, others will find them anyway. The point of having incomplete drafts up on the website (and in SVN) is that everybody has the same chance of seeing the draft. (Also note that the website version is the first hit if you type PEP 444 into a search engine.) If it's incomplete in places, just put XXX markers in it. People are used to this. Publication to the website does not imply any kind of approval -- it just is a mechanism for people to comment on a draft in a uniform way. (Also, a detailed SVN history might help people see the relevant changes -- a big bulk update doesn't shed much light on what changed since it looks like *everything* changed.) PEP is an excellent solution that should be quick to adopt. My PEP 444 rewrite takes a fundamentally different approach in an attempt to simplify and solve broader problems than pure compatibility. It might be good if you summarized the differences, either here (on the list) or in the PEP itself. Unlike the documents issued by some standards bodies, Python PEPs are meant to be readable documents, and can contain sections about motivation, history, examples, whatever else the author deems likely to sway its acceptance. The formal specification itself can be in a section labeled as such. (PS: I saw you just posted a quick summary, for which I am grateful. Maybe you can add a more thorough one to the PEP itself.) First, it would be great if Alice could prepare a version of her draft in the format required for PEPs, and submit it to the PEP editors. I will make this a priority. Great! -- --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
Re: [Web-SIG] PEP 444 != WSGI 2.0
On Sun, Jan 2, 2011 at 12:55 PM, Masklinn maskl...@masklinn.net wrote: On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote: On 2011-01-02 11:14:00 -0800, Chris McDonough said: I'd suggest we just embrace it, adding minor tweaks as necessary, 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. If I remember the previous Web3 discussion correctly, the result was basically that async has no business being shoehorned in WSGI, that WSGI's model is fundamentally unfit for async and you can't correctly support sync and async with the same spec, and therefore an asynchronous equivalent to WSGI should be developed separately, in order to correctly match the needs of asynchronous servers and interfaces, without the cruft and inadequacies of being forked from a synchronous gateway model. Masklinn, those are pretty strong words (bordering on offensive). I'm sure Alice has a different opinion. Alice, hopefully 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 (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
Re: [Web-SIG] PEP 444 != WSGI 2.0
On 2011-01-02, at 23:16 , Alice Bevan–McGregor wrote: (Just trying to keep this thread from degenerating into a shouting match.) I missed how his statements could be construed as offensive. :/ I missed it as well (though my report might have been brusque), and definitely didn't intent it to be offensive. I interpreted the multiple you can't references to be careless shorthand Yes, it was intended as a short report from the previous discussion's gist/result (or more precisely my potentially incorrect recollection of it), and aimed at suggesting that you check out that previous thread, not as a statement of fact (let alone personal criticism or attacks). ___ 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
Re: [Web-SIG] PEP 444 != WSGI 2.0
At 12:38 PM 1/2/2011 -0800, Alice BevanMcGregor wrote: On 2011-01-02 11:14:00 -0800, Chris McDonough said: I'd suggest we just embrace it, adding minor tweaks as necessary, 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. Actually, it's the other way 'round. I wrote off async for PEP 333 because the competing, incompatible solutions that already existed lacked sufficient ground to build a spec on. In effect, any direction I took would effectively have either blessed one async paradigm as the correct one, or else been a mess that nobody would've used anyway. And this condition largely still exists today: about the only common ground between at least *some* async Python frameworks today is the use of greenlets... but if you have greenlets, then you don't need a fancy async API in the first place, because you can just block during I/O from the POV of the app. The existence of a futures API in the stdlib doesn't alter this much, either, because the async frameworks by and large already had their own API paradigms for doing such things (e.g. Twisted deferreds and thread/process pools, or generator/greenlet-based APIs in other frameworks). The real bottleneck isn't even that, so much as that if you're going to write an async WSGI application, WSGI itself can't define enough of an async API to let you do anything useful. For example, you may still need database access that's compatible with the async environment you're using... so you'd only be able to write portable async applications if they didn't do ANY I/O outside of HTTP itself! That being the case, I don't see how a meaningfully cross-platform async WSGI can ever really exist, and be attractive both to application developers (who want to run on many platforms) and framework developers (who want many developers to choose their platform). On 2011-01-02 12:00:39 -0800, Guido van Rossum said: Actually that does sound like an opinion on the technical merits. I can't tell though, because I'm not familiar enough with PEP 444 to know what the critical differences are compared to PEP . Could someone summarize? Async, distinction between byte strings (type returned by socket.read), native strings, and unicode strings, What distinction do you mean? I see a difference in *how* you're distinguishing byte, native, and unicode strings, but not *that* they're distinguished from one another. (i.e., PEP distinguishes them too.) thorough unicode decoding (moving some of the work from middleware to the server), What do you mean by thorough decoding and moving from middleware to server? Are these references to the redundant environ variables, to the use of decoded headers (rather than bytes-in-unicode ones), or something else? The async part is an idea in my head that I really do need to write down, clarified with help from agronholm on IRC. The futures PEP is available as a pypi installable module, is core in 3.2, and seems to provide a simple enough abstract (duck-typed) interface that it should be usable as a basis for async in PEP 444. I suggest reviewing the Web-SIG history of previous async discussions; there's a lot more to having a meaningful API spec than having a plausible approach. It's not that there haven't been past proposals, they just couldn't get as far as making it possible to write a non-trivial async application that would actually be portable among Python-supporting asynchronous web servers. (Now, if you're proposing that web servers run otherwise-synchronous applications using futures, that's a different story, and I'd be curious to see what you've come up with. But that's not the same thing as an actually-asynchronous WSGI.) ___ 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
Re: [Web-SIG] PEP 444 != WSGI 2.0
At 02:21 PM 1/2/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-02 11:57:19 -0800, P.J. Eby said:
* -1 on the key-specific encoding schemes for the various CGI
variables' values -- for continuity of coding (not to mention
simplicity) PEP 's approach to environ encodings should beused.
(That is, the environ consists of bytes-in-unicode-form, rather
than true unicode strings.)
Does ISO-8859-1 not accomodate this for all but a small number of
the environment variables in PEP 444?
PEP requires that environment variables contain the bytes of the
HTTP headers, decoded using ISO-8859-1. The unicode strings, in
other words are restricted to code points in the 0-255 range, and are
really just a representation of bytes, rather than being a unicode
decoding of the contents of the bytes.
What I saw in your draft of PEP 444 (which I admittedly may be
confused about) is language that simply loosely refers to unicode
environment variables, which could easily be misconstrued as meaning
that the values could actually contain other code points.
To be precise, in PEP 333, the true unicode value of an environment
variable is:
environ[key].encode('iso-8859-1').decode(appropriate_encoding_for_key)
Whereas, my reading of your current draft implies that this has to
already be done by the server.
As I understand it, the problem with this is that the server
developer can't always provide such a decoding correctly, and would
require that the server guess, in the absence of any information that
it could use to do the guessing. An application developer is in a
better position to deal with this ambiguity than the server
developer, and adding configuration to the server just makes
deployment more complicated, and breaks application composability if
two sub-applications within a larger application need different decodings.
That's the rationale for the PEP approach -- it essentially
acknowledges that HTTP is bytes, and we're only using strings for the
API conveniences they afford.
* Where is the PARAMETERS variable defined in the CGI spec?
Whatservers actually support it?
It's defined in the HTTP spec by way of
http://www.ietf.org/rfc/rfc2396.txt URI Syntax. These values are
there, they should be available. (Specifically semi-colon separated
parameters and hash-separated fragment.)
I mean, what web servers currently provide PARAMETERS as a CGI
variable? If it's not a CGI variable, it doesn't go in all caps.
What's more, the spec you reference points out that parameters can be
placed in *each* path-segment, which means that they would:
1) already be in PATH_INFO, and
2) have multiple values
So, -1 on the notion of PARAMETERS, since AFAICT it is redundant, not
CGI, and would only hold one parameter segment.
* The language about empty vs. missing environment variables
appears to have disappeared; without it, the spec is ambiguous.
I will re-examine the currently published PEP 444.
I don't know if it's in there or not; I've read your spec more
thoroughly than that one. I'm referring to the language from PEP 333
and its successor, with which I'm much more intimately familiar.
Indeed. I do try to understand the issues covered in a broader
scope before writing; for example, I do consider the ability for new
developers to get up and running without worrying about the example
applications they are trying to use work in their version of Python;
thus /allowing/ native strings to be used as response values on Python 3.
I don't understand. If all the examples in your PEP use b'' strings
(per the 2.6+ requirement), where is the problem?
They can't use WSGI 1(.0.1) code examples at all (as your draft isn't
backward-compatible), so I don't see any connection there, either.
Byte strings are still perferred, and may be more performant,
Performance was not the primary considerations; they were:
* One Obvious Way
* Refuse The Temptation To Guess
* Errors Should Not Pass Silently
The first two would've been fine with unicode; the third was the
effective tie-breaker. (Since if you use Unicode, at some point you
will send garbled data and end up with an error message far away from
the point where the error occurred.)
I certainly will; I just need to see concrete points against the
technical merits of the rewritten PEP
Well, I've certainly given you some, but it's hard to comment other
than abstractly on an async spec you haven't proposed yet. ;-)
Nonetheless, it's really important to understand that the PEP process
(especially for Informational-track standards) is not so much about
technical merits in an absolute sense, as it is about *community consensus*.
And that means it's actually a political and marketing process at
least as much as it is a technical one. If you miss that, you may
well end up with a technically-perfect spec (in the sense that nobody
gives you any additional concrete points against the technical
Re: [Web-SIG] PEP 444 != WSGI 2.0
Until the PEP is approved, it's just a suggestion. So for it to really be WSGI 2 it will have to go through at least some approval process; which is kind of ad hoc, but not so ad hoc as just to implicitly happen. For WSGI 2 to happen, someone has to write something up and propose it. Alice has agreed to do that, working from PEP 444 which several other people have participated in. Calling it WSGI 2 instead of Web 3 was brought up on this list, and the general consensus seemed to be that it made sense -- some people felt a little funny about it, but ultimately it seemed to be something everyone was okay with (with some people like myself feeling strongly it should be WSGI 2). I'm not sure why you are so stressed out about this? If you think it's really an issue, perhaps 2 could be replaced with 2alpha until such time as it is approved? On Sat, Jan 1, 2011 at 8:02 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: Can we please clear up a matter. GothAlice (don't know off hand there real name), keeps going around and claiming: After some discussion on the Web-SIG mailing list, PEP 444 is now officially WSGI 2, and PEP is WSGI 1.1 In this instance on web.py forum on Google Groups. I have pointed out a couple of times to them that there is no way that PEP 444 has been blessed as being the official WSGI 2.0 but they are not listening and are still repeating this claim. They can't also get right that PEP clearly says it is still WSGI 1.0 and not WSGI 1.1. If the people here who's opinion matters are quite happy for GothAlice to hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that happens, I will voice my objections by simply not having anything to do with WSGI 2.0 any more. Graham ___ 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/ianb%40colorstudy.com -- Ian Bicking | http://blog.ianbicking.org ___ 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
