Re: [Web-SIG] WSGI: allowing short reads
I am taking full responsibility for this inconsistency. The original read(n) used stdio's fread(), which reads exactly n bytes or until EOF, whichever comes first. The switch to 3.0 might have been a good time to fix this, but we didn't, and now it's too late. If I had to do it over again I would have read(n) return up to n bytes using at most 1 syscall, and readexactly(n) return n bytes or bust (raising EOFError if EOF is hit before n bytes are seen). This is what asyncio streams use and what I recommend for stream-like APIs that don't require strict compatibility. Note that read() without parameter and read(-1) are also special (reading everything until EOF). I think this is unambiguous and doesn't need to be fixed. On Sat, Sep 27, 2014 at 5:00 AM, Antoine Pitrou anto...@python.org wrote: Hi, Robert Collins robertc@... writes: https://github.com/python-web-sig/wsgi-ng/issues/5 tl;dr - we don't specify whether read(size) has to return size bytes or just not more than size, today. the IO library is clear that read(n) returns up to n, and also offers read1 that guarantees only one read call. I think you've got things mixed up. There are two different things in the IO library (which is really the 3.x IO stack): * buffered binary I/O has read(n) and read1(n): - read(n) will block until n bytes are received (except for non-blocking fds) - read1(n) will issue at most one system call and can return fewer than n bytes * raw binary I/O only has read(n): - read(n) will issue at most one system call and can return fewer than n bytes So, depending on which layer you are placing yourself on, one or the other of your statements is wrong. That said, it would be reasonable for WSGI to expose the raw I/O layer, IMHO. Prettifying libraries can wrap it inside a BufferedReader if they like. Note that I once proposed generalized prefetching on I/O streams, but it was rejected: https://mail.python.org/pipermail/python-ideas/2010-September/008179.html (skip to the prefetch() proposal) It was in the context of improving streamed unpickling, which is a problem 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: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/guido%40python.org -- --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
[Web-SIG] Flurry of old posts appearing
Today (Sept 15, 2014) I just received several posts on web-sig that were apparently first posted in May. An example is a post by mouad ben with subject Connection close when response is ready. Did some kind of moderator queue just get unplugged? Or should I assume these were held up 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
Re: [Web-SIG] Flurry of old posts appearing
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 jans...@parc.com wrote: Guido van Rossum gu...@python.org wrote: Did some kind of moderator queue just get unplugged? Yep. First-time posts by new members. Bill -- --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
Re: [Web-SIG] [python-tulip] Re: [Python-Dev] wsgi validator with asynchronous handlers/servers
Hi Luca, Unfortunately I haven't thought yet about the interactions between WSGI and Tulip or PEP 3156. While I am pretty familiar with WSGI, I have never used its async features, so I can't be much of a help. My best guess is that we won't make any changes to WSGI to support PEP 3156 in Python 3.4, but that once that is out, some folks will come up with an improved design for WSGI that supports interoperability with standard async event loops. OTOH, maybe you can read up on the PEP and check out the Tulip implementation ( http://code.google.com/p/tulip/) and maybe you can come up with a suitable design for integrating PEP 3156 into WSGI? Though it may have to be named WSGI 2.0 to emphasize that it is backwards incompatible. --Guido On Sun, Mar 24, 2013 at 2:18 PM, Luca Sbardella luca.sbarde...@gmail.comwrote: Hello, first time here, I'm Luca and I write lots of python of the asynchronous variety. This question is about wsgi and the way pulsar http://quantmind.github.com/pulsar/ handles asynchronous wsgi responses. Yesterday I sent a message to the python-dev mailing list regarding wsgiref.validator, this is the original message I have an asynchronous wsgi application handler which yields empty bytes before it is ready to yield the response body and, importantly, to call start_response. Something like this: def wsgi_handler(environ, start_response): body = generate_body(environ) body = maybe_async(body) while is_async(body): yield b'' start_response(...) ... I started using wsgiref.validator recently, nice little gem in the standard lib, and I discovered that the above handler does not validate! Disaster. Reading pep the application *must* invoke the start_response() callable before the iterable yields its first body bytestring, so that the server can send the headers before any body content. However, this invocation *may* be performed by the iterable's first iteration, so servers *must not* assume that start_response() has been called before they begin iterating over the iterable. The pseudocode above does yields bytes before start_response, but they are not *body* bytes, they are empty bytes so that the asynchronous wsgi server releases the eventloop and call back at the next eventloop iteration. And the response was PJ Eby wrote: The validator is correct for the spec. You *must* call start_response() before yielding any strings at all. Thanks for response PJ, that is what I, unfortunately, didn't want to hear, the validator being correct for the spec means I can't use it for my asynchronous stuff, which is a shame :-((( But why commit to send headers when you may not know about your response? Sorry if this is the wrong mailing list for the issue, I'll adjust as I go along. Because async was added 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 programming API to Python). and so here I am. I know tulip is on its early stages but is there anything on the pipeline about wsgi? Happy to help if needed. Regards Luca -- --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] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)
On Wed, Jan 12, 2011 at 2:34 PM, Alice Bevan–McGregor al...@gothcandy.com 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 24 hours, can PEP be accepted? It seems a lot of people are waiting for a decision that enables implementers to go ahead and claim PEP 333[3] compatibility. PEP 444 can take longer. With the lack of responses, can I assume this has been or will be shortly marked as accepted? Yep. Phillip, can you do the honors? I look forward to updating WebCore with compatibility. -- --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] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)
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 24 hours, can PEP be accepted? It seems a lot of people are waiting for a decision that enables implementers to go ahead and claim PEP 333[3] compatibility. PEP 444 can take longer. --Guido On Fri, Jan 7, 2011 at 4:56 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: On 8 January 2011 02:55, P.J. Eby p...@telecommunity.com wrote: At 05:27 PM 1/7/2011 +1100, Graham Dumpleton wrote: Another thing though. For output changed to sys.stdout.buffer. For input should we be using sys.stdin.buffer as well if want bytes? %$*()%!!! Sorry, still getting used to this whole Python 3 thing. (Honestly, I don't even use Python 2.6 for anything real yet.) Good thing I tried running this. Did we all assume that someone else was actually running it to check it? :-) Well, I only recently started changing the examples to actual Python 3, vs being the old Python 2 examples. Though, I'm not sure anybody ever ran the 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 -- --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] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)
On Fri, Jan 7, 2011 at 7:35 AM, P.J. Eby p...@telecommunity.com wrote: At 05:00 PM 1/7/2011 +1100, Graham Dumpleton wrote: Stupid question first. When running 2to3 on the example CGI code, Don't do that. It's supposed to already be Python 3 code. ;-) It did, however, reveal a bug where I have not in fact done the correct Python 3 thing: if headers_sent: # Re-raise original exception if headers sent - raise exc_info[0], exc_info[1], exc_info[2] + raise exc_info[0](exc_info[1]).with_traceback(exc_info[2]) finally: exc_info = None # avoid dangling circular ref Can somebody weigh in on what the correct translation here is? The only real Python 3 coding I've done 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
Re: [Web-SIG] PEP 444 feature request - Futures executor
If it's optional, what's the benefit for the app of getting it through WSGI instead of through importing some other standard module? The API of the executor will require a lot of thought. I worry that this weighs down the WSGI standard with the responsibility of coming up with the perfect executor API, and if it's not quite perfect after all, servers are additionally required to support the standard but suboptimal API effectively forever. Or they can choose not to provide it, in which case it was a waste of time putting it in WSGI. On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell tfarr...@owassobible.org wrote: There has been much discussion about how to handle async in PEP 444 and that discussion centers around the use of futures. However, I'm requesting that servers _optionally_ provide environ['wsgi.executor'] as a futures executor that applications can use for the purpose of doing something after the response is fully sent to the client. This is feature request is designed to be concurrency methodology agnostic. Some example use cases are: - send an email that might block on a slow email server (Alice, I read what you said about Turbomail, but one product is not the solution to all situations) - initiate a database vacuum - clean a cache - build a cache - compile statistics When serving pages of an application, these are all things that could be done after the response has been sent. Ideally these things don't need to be done in a request thread and aren't incredibly time-sensitive. It seems to me that futures would be an ideal way of handling this. Thoughts? ___ 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-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 Async
On Thu, Jan 6, 2011 at 8:49 PM, P.J. Eby p...@telecommunity.com wrote: At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote: Tossing the idea around all day long will then, of course, be happening regardless. Unfortunately for that particular discussion, PEP 3148 / Futures seems to have won out in the broader scope. Do any established async frameworks or server (e.g. Twisted, Eventlet, Gevent, Tornado, etc.) make use of futures? PEP 3148 Futures are meant for a rather different purpose than those async frameworks. Those frameworks all are trying to minimize the number of threads using some kind of callback-based non-blocking I/O system. PEP 3148 OTOH doesn't care about that -- it uses threads or processes proudly. This is useful for a different type of application, where there are fewer, larger tasks, and the overhead of threads doesn't matter. The Monocle framework, which builds on top of Tornado or Twisted, uses something not entirely unlike Futures, though they call it Callback. I don't think the acceptance of PEP 3148 should be taken as forcing the direction that async frameworks should take. Having a ratified and incorporated language PEP (core in 3.2 w/ compatibility package for 2.5 or 2.6+ support) reduces the scope of async discussion down to: how do we integrate futures into WSGI 2 instead of how do we define an async API at all. It would be helpful if you addressed the issue of scope, i.e., what features are you proposing to offer to the application developer. While the idea of using futures presents some intriguing possibilities, it seems to me at first glance that all it will do is move the point where the work gets done. That is, instead of simply running the app in a worker, the app will be farming out work to futures. But if this is so, then why doesn't the server just farm the apps themselves out to workers? I guess what I'm saying is, I haven't heard use cases for this from the application developer POV -- why should an app developer care about having their app run asynchronously? So far, I believe you're the second major proponent (i.e. ones with concrete proposals and/or implementations to discuss) of an async protocol... and what you have in common with the other proponent is that you happen to have written an async server that would benefit from having apps operating asynchronously. ;-) I find it hard to imagine an app developer wanting to do something asynchronously for which they would not want to use one of the big-dog asynchronous frameworks. (Especially if their app involves database access, or other communications protocols.) This doesn't mean I think having a futures API is a bad thing, but ISTM that a futures extension to WSGI 1 could be defined right now using an x-wsgi-org extension in that case... and you could then find out how many people are actually interested in using it. Mainly, though, what I see is people using the futures thing to shuffle off compute-intensive tasks... but if they do that, then they're basically trying to make the server's life easier... but under the existing spec, any truly async server implementing WSGI is going to run the *app* in a future of some sort already... Which means that the net result is that putting in async is like saying to the app developer: hey, you know this thing that you just could do in WSGI 1 and the server would take care of it for you? Well, now you can manage that complexity by yourself! Isn't that wonderful? ;-) I could be wrong of course, but I'd like to see what concrete use cases people have for async. We dropped the first discussion of async six years ago because someone (I think it might've been James) pointed out that, well, it isn't actually that useful. And every subsequent call for use cases since 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. ___ 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-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] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)
On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight f...@fuhm.net wrote: On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote: At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote: Is that the last thing or do I need to go spend some time and write my own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have lying around and just do some final validation checks with a parallel implementation as a sanity check to make sure we got everything? This might be a good idea anyway. It would. In the meantime, though, I'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) ___ 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] [Python-Dev] PEP 3333: wsgi_string() function
On Tue, Jan 4, 2011 at 8:22 AM, Tres Seaver tsea...@palladion.com wrote: Note that Guido just recently wrote on that list that he considers that PEP to be de facto accepted. That was conditional on there not being any objections in the next 24 hours. There have been plenty, so I'm retracting that. -- --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] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)
On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss ja...@jacobian.org wrote: On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum gu...@python.org 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 accepted? Is there anything I can do to push that process forward? The lack of a WSGI answer on Py3 is the main thing that's keeping me, personally, from feeling excited about the platform. Once that's done I can feel comfortable coding to it -- and browbeating those who don't support it. I understand that PEP 444/Web3/WSGI 2/whatever might be a better answer, but it's clearly got some way to go. In the meantime, what's next to get PEP officially endorsed and accepted? I haven't heard anyone speak up against it, ever, since it was submitted. If no-one speaks up in the next 24 hours consider it accepted (and after that delay, anyone with SVN privileges can mark it thus). -- --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
any problem with frequent submissions, as long as new submissions of the same PEP incorporate any changes that the PEP editors made (e.g. ReST formatting fixes). (Another way to get new versions submitted to SVN would be to ask the other author of PEP 444, Armin Ronacher, to check it in; he has submit privileges.) The longer Alice's draft lingers on github, the less likely I think it is that it will ever be elevated to the official WSGI 2.0 standard. At the same time, I hope that web-sig and Graham can start discussing the technical merits of Alice's proposal, so that Alice can incorporate the feedback into her draft. It is my understanding that Alice primarily offered to improve the writing and precision of the PEP (although that doesn't mean she can't have an opinion on specific features), and that she is open to changes proposed by others. (If I were wrong about this, and Alice had an ax to grind, that would change things, and it might even make sense to have multiple competing proposals, each hopeful to once earn the WSGI 2.0 moniker. But I hope not.) Alice, I hope you can live with these recommendations. While it may place a burden on you to convert your draft to ReST and to have to maintain it that way, I think there is a much better chance of an open community discussion leading to a widely accepted standard if you start following the PEP rules set out in PEP 1 (and a few other low-numbered PEPs). 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. -- --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: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] Is PEP 3333 the final solution for WSGI on Python 3?
On Sun, Oct 24, 2010 at 10:17 AM, Georg Brandl g.bra...@gmx.net wrote: Am 24.10.2010 17:58, schrieb Chris McDonough: On Sun, 2010-10-24 at 17:16 +0200, Georg Brandl wrote: Am 24.10.2010 16:40, schrieb Chris McDonough: On Sun, 2010-10-24 at 10:17 +0300, Armin Ronacher wrote: I have to admit that my interest in Python 3 is not very high and I am most likely not the most reliable person when it comes to driving PEP 444 :) We should probably withdraw the PEP, then (unless someone else wants to step up and champion it), because neither am I. Don't give it up yet -- Deferring is probably the better option. TBH, unless someone has immediate interest in championing it, I'd 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 clearly what state it is in -- not obsolete, but without an active champion. And here I thought for a second you were changing the topic to Twisted. :-) -- --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] [Python-Dev] WSGI is now Python 3-friendly
On Sun, Sep 26, 2010 at 7:58 AM, Tres Seaver tsea...@palladion.com wrote: I hadn't realized that PEP 333 was never actually in the 'Final' status (de facto, it has been so for years, of course). Given that fact, and PJEs assurances, I think amending the PEP and then immediately declaring it final is reasonable. And who is going to give the PEP its stamp of approval? I'm sorry, but all this weasel-wording about how these changes aren't really changes and how this standard wasn't really a standard make me very uncomfortable. I'm happy approving Final status 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 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] [Python-Dev] WSGI is now Python 3-friendly
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org 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 approve a new PEP which includes PJE's corrections. Can we make it PEP , then? ;-) That works for me. Go for it. -- --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] [Python-Dev] WSGI is now Python 3-friendly
Since you have commit privileges, just do it. The PEP editor position mostly exists to assure non-committers are not prevented from authoring PEPs. Please do add a prominent note at the top of PEP 333 pointing to PEP for further information on Python 3 compliance or some such words. Add a 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 p...@telecommunity.com wrote: At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote: On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org 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 approve a new PEP which includes PJE's corrections. Can we make it PEP , then? ;-) That works for me. Go for it. Shall I just svn cp it, then (to preserve edit history), or wait for the PEP editor do it? -- --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] [Python-Dev] WSGI is now Python 3-friendly
On Sat, Sep 25, 2010 at 7:00 PM, P.J. Eby p...@telecommunity.com 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 set of textual corrections on the existing PEP 333. With the exception of the bytes change, I ruled out accepting any proposed amendments that would actually alter the protocol. The amendments are all either textual clarifications, clarifications of ambiguous/unspecified areas, or best-practice recommendations by implementors. (i.e., which are generally already implemented in major servers) Of those, IMO only textual clarifications ought to be made to an existing, accepted, widely implemented standards-track PEP. Clarifications of ambiguous/unspecified behavior can possibly rule as non-conforming implementations that used to get the benefit of the doubt. Best-practice recommendations also have the effect of changing (perceived) compliance. Really, what's the problem with creating a new PEP? PEPs are cheap -- it's getting the acceptance that's costly, and you've already gotten that part. It doesn't have to be long. You can still make pure textual clarifications to PEP 333 (basically, improve grammar) and add a pointer to the new PEP. Or, you can create a new PEP that is an updated copy of PEP 333, and just add a pointer to PEP 333 saying (especially in the context of Python 3) this PEP is now superseded by PEP . I strongly disagree with using (standards-track) PEPs as mutable documents -- before you know it people will have to use weasel words like compliant with PEP 333 as of date X to describe their software's conformity. If you add a new PEP #, software declared compliant with PEP 333 remains compliant (and some such software can now also claim compliance with the new PEP without any changes). The full list of things Graham and others have asked for or recommended would indeed require a 1.1 version at minimum, and thus a new PEP. But I really don't want to start down that road right now, and therefore hope that I can talk Graham or some other poor soul into shepherding a 1.1 PEP instead. ;-) That's fine. It will just be another PEP. (Seriously: through an ironic twist of fate, I have done nearly *zero* Python web programming since around the time I drafted the first spec in 2004, so even if it makes sense for me to finish PEP 333, it makes little sense for me to be starting a *new* one on the topic now!) Don't see this as a new spec. See it as a procedural issue. -- --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 (aka Web3)
Um, talk about a whopper of a topic change. None of that is on the table. Maybe for Python 4. And certainly not in web-sig. On Thu, Sep 16, 2010 at 12:32 PM, Massimo Di Pierro mdipie...@cs.depaul.edu wrote: Not sure this discussion belongs here but since you asked: I think it should have takes three/four more bold steps: 1) address the GIL issue completely by removing reference counting 2) add more support for lightweight threads (like stackless, erlang and go) 3) perhaps allow some mechanism for tainting data and do restricted execution 4) change name to avoid confusion ... and yet stress that it was almost 100% compatible with existing python code. I think a lot more people would have jumped on it from outside the existing community. The future is in multi core processors and lightweight threads. Of course I am not a developer and I do realize these things may be hard to accomplish. I also trust Guido's judgement more than my own in this respect so consider mine a wish more than a realistic suggestion. Massimo On Sep 16, 2010, at 2:16 PM, Ty Sarna wrote: On Sep 16, 2010, at 2:55 PM, Massimo Di Pierro wrote: My experience in various communities suggests that naming the new totally-bw-incompat thing the same as the old thing weakens both the new thing and the old thing, I share the same experience. Interesting. Do you feel that Python 3.x should have been named something other than Python? I think that would rather have weakened both 3.x and 2.x by suggesting a fork, placing the two in competition, when the goal 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-sig/guido%40python.org -- --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] Python 3.0 and WSGI 1.0.
On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer fuman...@aminus.org wrote: Good timing. We had been thinking to make everything strings except for SCRIPT_NAME, PATH_INFO, and QUERY_STRING, since these few are pulled from the Request-URI, which may be in any encoding. It was thought that the app would be best-qualified to decode those three. Argh. The *meaning* of these fields is clearly text. It would be most unfortunately if all apps were required to deal with decoding bytes for these (there is no choice any more, unlike in 2.x). I appreciate the sentiment that the encoding is unknown, but I would much prefer it if there was a default encoding that the app could override, or if there was some other mechanism whereby the app would not have to be bothered with decoding bytes unless it cared. Note that Py3k also treats filenames as text, with an optional escape hatch for using bytes that only very few apps will need to use. I hope to discuss that further this morning at the sprints. Turns out the cgi module in Python 3 only does text, not bytes. I considered submitting a patch to make it handle bytes for fp/environ but that became difficult quickly and may complicate 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: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Python 3.0 and WSGI 1.0.
On Wed, Apr 1, 2009 at 12:15 PM, Ian Bicking i...@colorstudy.com wrote:
On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum gu...@python.org wrote:
On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer fuman...@aminus.org wrote:
Good timing. We had been thinking to make everything strings except for
SCRIPT_NAME, PATH_INFO, and QUERY_STRING, since these few are pulled
from the Request-URI, which may be in any encoding. It was thought that
the app would be best-qualified to decode those three.
Argh. The *meaning* of these fields is clearly text. It would be most
unfortunately if all apps were required to deal with decoding bytes
for these (there is no choice any more, unlike in 2.x). I appreciate
the sentiment that the encoding is unknown, but I would much prefer it
if there was a default encoding that the app could override, or if
there was some other mechanism whereby the app would not have to be
bothered with decoding bytes unless it cared.
This might be fine, except it is hard. You can't just take arbitrary
bytes and do script_name.decode('utf8'), and then when you realize you
had it wrong do script_name.encode('utf8').decode('latin1').
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_params. (Perhaps you could have QUERY_STRING and
QUERY_BYTES.) The decode() call used to create the text strings could
use 'replace' as the error handler and the app could check for the
presence of the replacement character ('\ufffd') in the string to see
if there was a problem; or it could just work with the string
containing that character and report the user some kind of 40x or 50x
error. Frameworks (like webob) would of course do the right thing and
look for QUERY_BYTES before QUERY_STRING. QUERY_BYTES should probably
be optional.
--
--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
Re: [Web-SIG] Python 3.0 and WSGI 1.0.
On Wed, Apr 1, 2009 at 3:37 PM, P.J. Eby p...@telecommunity.com 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_params. (Perhaps you could have QUERY_STRING and
QUERY_BYTES.) The decode() call used to create the text strings could
use 'replace' as the error handler and the app could check for the
presence of the replacement character ('\ufffd') in the string to see
if there was a problem; or it could just work with the string
containing that character and report the user some kind of 40x or 50x
error. Frameworks (like webob) would of course do the right thing and
look for QUERY_BYTES before QUERY_STRING. QUERY_BYTES should probably
be optional.
The big problem I see with this approach is that any middleware that
operates on these environment keys would have to be changed.
I think perhaps the problem here is the assumption that the environ
dictionary has to be a straight-up copy of os.environ, when it can be
whatever we want it to be. If wsgiref or other CGI-WSGI gateways have to
change to get the environ set up correctly, this is less of a problem than
forcing everybody to rewrite their middleware and apps.
Well I would assume that changing the type of these variables to bytes
would *also* cause problems for a lot of middleware.
The proposal that the bytes values should be in the 'wsgi.*' namespace
would work for me too.
Note that os.environ already has some not-entirely-solved problems
with encodings, which we currently try to pretend don't exist...
--
--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
Re: [Web-SIG] Time a for JSON parser in the standard library?
On Mon, Mar 10, 2008 at 9:08 AM, Jonathan Ellis [EMAIL PROTECTED] wrote: On Mon, 10 Mar 2008 09:37:35 -0400, Mark Ramm [EMAIL PROTECTED] said: Is it time there was a JSON codec included in the python standard library? 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 put it. -- --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
Re: [Web-SIG] Time a for JSON parser in the standard library?
On Mon, Mar 10, 2008 at 7:23 PM, James Bennett [EMAIL PROTECTED] wrote: On Mon, Mar 10, 2008 at 8:37 AM, Mark Ramm [EMAIL PROTECTED] wrote: 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. I'd tentatively agree, though I recall seeing a post not long ago (which I am currently unable to find) from the author of jsonlib lamenting the fact that most of the other JSON modules for Python had various significant inconsistencies with the RFC. While authors of competing tools should be taken with a grain of salt, I do think compliance with the spec is an important factor for any particular module that might be blessed with stdlib membership, and 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.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Fwd: [Baypiggies] News flash: Python possibly guilty in excessive DTD traffic
-- Forwarded message -- From: Keith Dart ♂ [EMAIL PROTECTED] Date: Feb 8, 2008 8:03 PM Subject: [Baypiggies] News flash: Python possibly guilty in excessive DTD traffic To: [EMAIL PROTECTED] http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic This is interesting. I've noticed that when you use Python's XML package in validating mode it does try to fetch the DTD. Be careful when you use that. -- -- ~ Keith Dart [EMAIL PROTECTED] public key: ID: 19017044 http://www.dartworks.biz/ = ___ Baypiggies mailing list [EMAIL PROTECTED] To change your subscription options or unsubscribe: http://mail.python.org/mailman/listinfo/baypiggies -- --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
Re: [Web-SIG] WSGI, Python 3 and Unicode
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 PROTECTED] wrote: * When running under Python 3, servers MUST provide a text stream for wsgi.errors In Python 3, what happens if user code attempts to output to a text stream a byte string? Ie., what would be displayed? Nothing. You get a TypeError. Hmmm, this in itself could be quite a pain for existing code where people have added debug code to print out details from request headers (if now to be passed as bytes), or part of the request content. Sorry, I was just talking about the write() method on a text stream. The print() function in 3.0 will print the repr() of the bytes. Example: Python 3.0a2 (py3k, Dec 10 2007, 09:38:42) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type help, copyright, credits or license for more information. a = bxyz print(a) b'xyz' b = babc\377def print(b) b'abc\xffdef' (Note that this works because print() always calls str() on the argument and bytes.str is defined to be the same as bytes.repr.) What is the suggested way of best dumping out bytes for debugging purposes so one does not have to worry about encoding issues, just use repr()? Just use print(). Also, if wsgi.errors is a text stream, presume that if a WSGI adapter has to internally map this to a C char* like API for logging that it would need to apply standard Python encoding to yield usable char* string for output. The encoding can/must be specified per text stream. But what should the encoding associated with the wsgi.errors stream be? Depends on the platform and your requirements. If code which outputs text to wsgi.errors can use any valid Unicode character, if one sets it to US-ASCII encoding, then chance that logging output will fail because of characters not being valid in that character set. If one instead uses UTF-8, then potentially have issues where that byte string coming out other end of text stream is passed to C API functions. Issues might arise here where C API not expecting variable width character encoding. I'll freely admit I am not across all this Unicode encode/decode stuff as I don't generally have to deal with foreign languages, but seems to be a few missing details in this area which need to be filled out for a modified WSGI specification. The goal of this part of Py3k is to make it more obvious when you haven't thought through your encoding issues enough by failing as soon as (encoded) bytes meet (decoded) characters. Of course, you can still run into delayed trouble by using an inappropriate encoding, which only shows up when there is an actual encoding or decoding error; but at least you will have carefully distinguished between encoded and decoded text throughout your program, so the fix is now to change the encoding rather than having to restructure your code to properly separate encoded and decoded text. -- --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
Re: [Web-SIG] WSGI, Python 3 and Unicode
On Dec 8, 2007 12:37 AM, Graham Dumpleton [EMAIL PROTECTED] wrote: On 08/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote: * When running under Python 3, servers MUST provide a text stream for wsgi.errors In Python 3, what happens if user code attempts to output to a text stream a byte string? Ie., what would be displayed? Nothing. You get a TypeError. Also, if wsgi.errors is a text stream, presume that if a WSGI adapter has to internally map this to a C char* like API for logging that it would need to apply standard Python 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/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI, Python 3 and Unicode
On Dec 6, 2007 4:15 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:13 AM 12/7/2007 +1100, Graham Dumpleton wrote:
Has anyone had any thoughts about how WSGI is going to made to work
with Python 3?
From what I understand about changes in Python 3, the main issue seems
to be the removal of string type in its current form.
This is an issue as WSGI specification currently states that status,
header names/values and the items returned by the iterable must all be
string instances. This is done to ensure that the application has done
any conversions from Unicode, where knowledge about encoding would be
known, before being passed to WSGI adapter.
In Python 3 the default for string type objects will effectively be
Unicode. Is WSGI going to be made to somehow cope with that, or will
application instead be required to return byte string objects instead?
WSGI already copes, actually. Note that Jython and IronPython have
this issue today, and see:
http://www.python.org/dev/peps/pep-0333/#unicode-issues
On Python platforms where the str or StringType type is in fact
Unicode-based (e.g. Jython, IronPython, Python 3000, etc.), all
strings referred to in this specification must contain only code
points representable in ISO-8859-1 encoding (\u through \u00FF,
inclusive). It is a fatal error for an application to supply strings
containing any other Unicode character or code point. Similarly,
servers and gateways must not supply strings to an application
containing any other Unicode characters.
That may work for IronPython/Jython, where encoded data is represented
by the str type, but it won't be sufficient for Py3k, where encoded
data is represented using the bytes type. IOW, in IronPython/Jython,
u\u1234.encode('utf-8') returns a str instance: '\xe1\x88\xb4'; but
in 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 manage to pass
in Py3k though. ;-)
--
--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
Re: [Web-SIG] WSGI, Python 3 and Unicode
On Dec 6, 2007 8:00 PM, Ian Bicking [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: At 08:08 PM 12/6/2007 -0500, Adam Atlas wrote: On 6 Dec 2007, at 18:13, Graham Dumpleton wrote: In Python 3 the default for string type objects will effectively be Unicode. Is WSGI going to be made to somehow cope with that, or will application instead be required to return byte string objects instead? I'd say it would be best to only accept `bytes` objects; anything else would require some guesswork. Maybe, at most, it could try to encode returned Unicode objects as ISO-8859-1, and have it be an error if that's not possible. Actually, I'd prefer to look at it the other way around: a Python 3 WSGI server or middleware *may* accept bytes objects instead of str. This is relatively easy for the response side of things, but the request side is rather more difficult, since wsgi.input may need to be binary rather than text mode. (I think we can reasonably assume that wsgi.errors is a text mode stream, and should support a reasonable encoding.) wsgi.input definitely seems like it should be bytes to me. Unless we want to put the encoding process into the server. Not entirely infeasible, but a bit of a strain. And the request body might very well be binary, e.g., on a PUT. The CGI keys in the environment don't feel at all like bytes to me, but then they aren't unicode either. They can be unicode, again given a bit of work on the server side. Though unfortunately browsers are very poor at indicating their encoding for requests, and it ends up being policy and configuration as much as anything that determines the encoding of stuff like wsgi.input. I believe all request paths are UTF8 (?), but I'm not sure about QUERY_STRING. I'm a little fuzzy 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 Unicode with WSGI in 2.x though, as it is caused by something outside our control (HTTP and browsers). -- --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
Re: [Web-SIG] WebOb
2007/10/22, Ian Bicking [EMAIL PROTECTED]: I briefly looked at the tutorial and was put off a little by the interactive prompt style of the examples; that seems so unrealistic that I wonder if it wouldn't be better to just say put this in a file and run it like this? The side effect of doctesting is that docs sometimes look weird :-/ Personally, I find doctest a great tool for writing tests in certain situations; not so great for writing docs though. I'm not sure what form the docs should take. I'm open to suggestions. The extracted docs are actually reasonable as a reference, I think: http://pythonpaste.org/webob/class-webob.Request.html http://pythonpaste.org/webob/class-webob.Response.html Hm, these are mostly alphabetical listings of individual methods and properties. I'm still hoping for something that I can read from top to bottom in 10 minutes and get an idea of what this is and how to use it. For realistic use cases, some kind of infrastructure is necessary. How realistic are we talking? I'm thinking of something that I can test by pointing my browser to localhost:8080 or similar. For CGI scripts, the standard library's CGIHTTPServer would suffice. How hard is it to create something similar for WSGI or for webob? I suppose a simple example using the wsgiref server and a plain WSGI app would suffice. Even a very small framework (e.g., http://svn.pythonpaste.org/Paste/apps/FlatAtomPub/trunk/flatatompub/dec.py) improves that considerably, but probably isn't worth introducing. It's hard to judge that code since it has zero documentation. I was more looking for something that has a main() which is called when invoked as a script. A quick summary of differences in the API and some other request/response objects out there: http://pythonpaste.org/webob/differences.html I'd include more frameworks, if you can point me to their request/response API documentation (e.g., I looked but couldn't find any for Zope 3). I'm not too familiar with other frameworks (having always hacked my own, as it's so easy :-). Any chance of a summary that's not a tutorial 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 also be possible, covering just the most important attributes and with a quick listing of others (like all the properties for the individual HTTP headers). Yes please. -- --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
Re: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design)
On 7/8/07, Jim Fulton [EMAIL PROTECTED] wrote: [quoting Ian Bicking] I've tried to encourage people to use this, but they get stuck on the word paste, so there's not many other people who consume or produce these entry points except for use with Paste or related packages (Pylons, etc). I'm not sure what to do about that, except perhaps to reset people's opinions with this rewrite. Well, this touches a nerve with me. I have a similar problem with people rejecting out of hand anything that happens to live in the zope or even the zc namespace. Similarly, at PyCon, I try to always give at least talk that I think will be generally interesting to the Python community at large, yet many people tend to assume that these are Zope specific. I think this behavior is extremely unhealthy for the Python community. Paste deploy is the only effort I've seen to provided a much-needed glue layer for WSGI. It doesn't matter one bit to me what it's called. It tries to fill a basic need. Now I'm all for competition. If someone really wanted to come up with something better, then I wouldn't mind seeing someone try, but nothing else is happening AFAICT. I certainly have other things I want to work on. Paste Deploy is a really good start and, FWIW, the Zope community is embracing it. I don't understand why your talks are assumed to be uninteresting to non-Zope-users (how much evidence do you have?), but I have a feeling that the branding of generally useful functionality with a particular framework's name is just bad politics. I agree that it's unhealthy for that functionality to be ignored, but the solution is not to complain about people's behavior (that's rarely going to change the behavior being deplored) but to become sensitive to the problem that the brand *apparently* causes and switch to a different brand. Some brands have this problem more than others; I would expect that Marc Andre Lemburg's MX brand doesn't suffer much because it's being marketed as a loosely connected collection of various independently usable subpackages. However the Zope brand is very strongly associated with the web application framework of that 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 be easier (as Ian observed). -- --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
Re: [Web-SIG] wsgiref questions
On 12/22/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: We decided to add chunking encoding to our own server, it wasn't all that hard. Hopefully you will release this code as part of wsgiref and let the community benefit from it, right? We didn't modift wsgiref, we added it to a proprietary module; and I don't think our code has anything to offer over what's already available through other channels, such as the CherryPy server. (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 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.) -- --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
Re: [Web-SIG] wsgiref questions
On 12/22/06, Chad Whitacre [EMAIL PROTECTED] wrote: Getting another piece of open source code added to Google's infrastructure (and learning how to use it) would have been an order of magnitude more effort than writing the ~50 lines of code that we ended up adding. That's striking. Out of curiosity, can I ask what exactly the bureaucracy looks like for open source code to be used at Google? Since we're talking WSGI the learning curve is pretty much nil, so the bureaucracy must be heavy. Is it mostly a 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 Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
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 struggling to use wsgiref behind some Googlish infrastructure, and one of the issues we find is that there is code that forbids hop-by-hop headers. Unfortunately we have a reason to send one (Transfer-encoding). Are you sure it's not a Content-Encoding? No, chunked is definitely a transfer encoding. What's the reason behind their prohibition, and what would be the right way to do this? See the thread here for the original rationale: http://mail.python.org/pipermail/web-sig/2004-September/000879.html Well, we're using wsgiref's simple_server which only speaks HTTP/1.0, but we really need to speak HTTP/1.1 and use chunked. Where do you recommend we put the chunking instead? It's expected that an HTTP/1.1 server would handle chunking in the case where a WSGI app yields individual blocks, assuming that the client supports chunking and the server chooses to do it that way. The way the spec is written, the server *must* ensure that each yielded chunk is transmitted to the client before the application is asked for the next chunk. However, it's the server's choice as to whether the chunks will just be streamed or transmitted using chunked encoding. wsgiref does have this comment at one point in the code (wsgiref.handlers), btw: # XXX Try for chunked encoding if origin server and client is 1.1 This is the place where you could try to add support for doing this. I.e., that's the place where you'd add the Transfer-Encoding header, after checking for client support. Yeah, but we'd like not to edit wsgiref, so our code won't depend on a hacked version of it... By the way, if your goal is just to ensure that data is written to the client as its yielded by the application, that can be done without needing the chunked encoding. My understanding is that all chunked encoding is good for is sending data of unknown length over a persistent connection. simple_server doesn't support persistent connections (and WSGI doesn't have connections), so chunking is of use only if you have some crazy kind of client that needs the chunking for some reason known only to its developers. :) And guess what, that's exactly the situation we're in. -- --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
Re: [Web-SIG] WSGI, cgi.FieldStorage incompatibility
On 9/29/06, Michael Kerrin [EMAIL PROTECTED] wrote: But the current implementation of cgi.FieldStorage in the 2.4.4 branch and on Python 2.5 does call readline with the size argument. It has started to do this in response to the Python bug #1112549 - cgi.FieldStorage memory usage can spike in line-oriented ops. See http://sourceforge.net/tracker/index.php?func=detailaid=1112549group_id=5470atid=105470 Since it is reasonable for a WSGI application to use cgi.FieldStorage I am wondering whether cgi.FieldStorage or the WSGI specification needs to changed in order to solve this incompatibility. Originally I thought it was cgi.FieldStorage that needs to be changed, and hence tried to fix it by wrapping the input stream so that the readline method always uses the read method on the input stream. While this seems to work for me it introduces a level of complexity in the cgi.py file, and possible some other bugs, that makes me think that adding the size argument for readline into the WSGI specification isn't such bad idea after all. Since that change to cgi.py was a 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 Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib
On 5/2/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: I've been following the discussion around adding wsgiref to the stdlib and it sounds like a very good idea. However I'm a little concerned as it seems only wsgiref has been suggested to be included. I wonder if you guys intend to review other implementations before going ahead? I ask this because the simple_server.py module of wsgiref says: It has not been reviewed for security issues, however, and we strongly recommend that you use a real web server for production use. Therefore, I wonder what is the final purpose of such addition? Is it merely to have default WSGI implementation that *might* not be scalable in production? I have nothing against wsgiref mind you. I'm fairly sure Phillip has done a great job but I simply wanted to know if you would consider checking other implemetations. Anything that could be considered of sufficiently industrial strength to be secure and scalable in production would necessarily be such a large project, such a complex code base, 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 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] 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/)
___
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] 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/) ___ 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] WSGI Server implementation which runs as a Windows service
Support for Windows services is part of win32all, not core Python. --Guido On 4/28/06, Paul Moore [EMAIL PROTECTED] wrote: I'm starting to play with WSGI, and I'd really like to find a reasonable WSGI server implementation which will run as a Windows service. I had a go with the CherryPy (2.2.1) WSGI server, and it didn't seem to play nicely with the standard run-cherrypy-as-a-service code I've used before. I may have been doing something wrong - pointers gratefully accepted if so, but I'm equally open to other options. My basic reason is to get away from mod_python - I'd like to have a WSGI server service, which serves my various web applications, and just use Apache as a proxy. Mounting WSGI apps on a single service seems likely to be a much easier approach than wrapping every 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/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
Re: [Web-SIG] minor bug in PEP 333 example
Thanks, fixed. On 4/2/06, Doug Porter [EMAIL PROTECTED] wrote: There is a minor bug in the middleware example in PEP 333. --- pep-0333.txt.orig Sun Apr 2 17:52:46 2006 +++ pep-0333.txtSun Apr 2 17:53:02 2006 @@ -352,7 +352,7 @@ def __init__(self, application): self.application = application -def __call__(environ, start_response): +def __call__(self, environ, start_response): transform_ok = [] -- Doug Porter [EMAIL PROTECTED] ___ 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
Re: [Web-SIG] WSGI in standard library
Sorry folks, I'm going to have to do some serious load shedding if I ever want to get the Py3K effort under way. You are going to have to argue amongst yourselves about the best wsgi reference implementation to put into the standard library. As a starting point, the code you reference seems particularly underdocumented. --Guido On 3/15/06, Clark C. Evans [EMAIL PROTECTED] wrote: Guido, In the past few weeks it looks like CherryPy people have put in a serious effort cleaning-up their WSGI Server (so it does not have external dependencies, etc.). I'd like to applaud their effort and suggest that we might want to use their implementation as the basis of a built-in Python 2.5 standard library version of WSGI. http://svn.cherrypy.org/trunk/cherrypy/_cpwsgiserver.py Kind Regards, Clark On Mon, Feb 13, 2006 at 03:52:32PM -0600, Ian Bicking wrote: | I'm not set on production quality code, but I think the general | sentiment against that is entirely premature. The implementations | brought up -- CherryPy's | (http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's | (http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and | wsgiref's | (http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2view=markup) | are all pretty short. It would be better to discuss 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
Re: [Web-SIG] WSGI in standard library
On 2/16/06, Alan Kennedy [EMAIL PROTECTED] wrote: [Ian Bicking] Anyway, I'm +1 on the object [wsgiref's wsgi header manipulation class] going somewhere. I don't know if the parent package has to be named wsgi -- and wsgiref seems even stranger to me, as anything in the standard library isn't a reference implementation anymore, but an actual implementation. I personally like a package name like web. Everyone will know what that means (though it would start with most of the web related modules not in it, which is a problem). While we're on the subject, can we find a better home for the HTTP status codes-messages mapping? Integer status codes. http://mail.python.org/pipermail/web-sig/2004-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/) ___ 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] WSGI in standard library
On 2/15/06, Jean-Paul Calderone [EMAIL PROTECTED] wrote: HTTPS is orthogonal. Besides, how would you support it in the stdlib? It's currently not possible to write an SSL server in Python without a third-party library. Maybe someone would be interested in rectifying /that/? :) Yes, why do't you volunteer? Theer's absolutely no fundamental reason why we can't support server-side SSL when we do support client-side SSL in httplib.py, except that someone has to write the code -- the same OpenSSL library can be used. Well, I can see one *practical* 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 (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
Re: [Web-SIG] WSGI in standard library
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 wholly | agree. Fantastic. I just don't think it is appropriate to have a toy in the standard library. So we disagree fundamentally -- IMO sometimes a toy is right for the standard library, for example when anything considered a non-toy would have vast reams of platform-specific code, or when the design space for non-toys is simply too vast to pick just one solution. The standard library should only have one of each thing it supports. Example: I doubt that the standard library will ever contain a non-toy GUI library or a non-toy web framework. Developing one of these is a huge effort, and there are serious trade-offs in choosing one. For example, professionals disagree on whether Django, Cheetah or Myghty is the best templating language. Until one has won (an unlikely outcome) none of these should be promoted to standard library status, because it would do a disservice to those users for whom the chosen one is the wrong choice. So instead, the standard library gets something like string.Template, which is markedly less powerful, but also less controversial. On Tue, Feb 14, 2006 at 12:00:57PM -0800, Guido van Rossum wrote: | Let's make it so. I propose to add wsgiref to the standard library and | nothing more. I propose we add wsgiref, but look at other implementations and steal what ever you can from them. This is not a huge chunk of code -- no reason why you can't have the best combination of features and correctness. But it would need to be done *before* it is submitted to the standard library. What you propose sounds like a big task, while what I'm proposing is a simple matter of slightly cleaning up a few files and checkin them in. Also, stealing whatever you can might easily be considered a license for feature bloat, which would be unpythonic. -- --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
Re: [Web-SIG] WSGI in standard library
On 2/14/06, Alan Kennedy [EMAIL PROTECTED] wrote: [Ian Bicking] Note that the scope of a WSGI server is very very limited. It is quite distinct from an XMLRPC server from that perspective -- an XMLRPC server actually *does* something. A WSGI server does nothing but delegate. and I'm not set on production quality code, but I think the general sentiment against that is entirely premature. The implementations brought up -- CherryPy's (http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's (http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and wsgiref's (http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2view=markup) are all pretty short. It would be better to discuss the particulars. Is there a code path in one or more of these servers which you think is unneeded and problematic? A few points. 1. My opinion is not relevant to whether/which WSGI server goes into the standard library. What's required is for someone to propose to python-dev that a particular WSGI server should go into the standard library. I imagine that the response on python-dev to the proposer is going to be along the lines of Will you be maintaining this? If/when python-dev is happy, then it'll go into the distribution. 2. What's wrong with leaving the current situation as-is, i.e. the available WSGI implementations are listed on the WSGI Moin page http://wiki.python.org/moin/WSGIImplementations 3. If I had to pick one of the 3 you suggested, I'd pick the last one, i.e. PJE's, because it fulfills exactly the criteria I listed - It's pretty much the simplest possible implementation, meaning it's easiest to understand. - It's based on the existing *HttpServer hierarchy - It's got a big 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 reviewed for security issues, however, and we strongly recommend that you use a real web server for production use. Let's make it so. I propose to add wsgiref to the standard library and nothing more. -- --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
Re: [Web-SIG] WSGI in standard library
On 2/14/06, Blake Winton [EMAIL PROTECTED] wrote: Let's make it so. I propose to add wsgiref to the standard library and nothing more. Will you be maintaining this? ;) I'd expect we could twist Phillip's arm to maintain it; he's not expecting 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@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] WSGI in standard library
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 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
Re: [Web-SIG] WSGI in standard library
On 2/14/06, Alan Kennedy [EMAIL PROTECTED] wrote: Well, I'm sure we all want our favourite server in the stdlib ;-) But a few things have to happen first. Priority #1: Make the requisite server a single standalone module. Huh? What makes you think this? There are plenty of packages in the standard library. It obviously needs to be free from dependencies on things that aren't in the standard library. But I don't see the need to remove the package structure. (The only cleanup I'd like to see is to remove the strange occurrences of *many* 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.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] My original template API proposal
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 (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
Re: [Web-SIG] A trivial template API counter-proposal
On 2/5/06, Ian Bicking [EMAIL PROTECTED] wrote: * There was an ad hoc standardization happening with TG and Buffet. * Other people were becoming interested. * Discussion was happening on the TG list, where most people on the TG list were not particularly interested about this sort of thing. * There are still several outstanding issues with the spec. * People came upon this ad hoc standard rather randomly through word of mouth, and Peter Hunt thought that maybe the spec should be promoted more. * Almost everyone doing stuff on the web cares about templates. * Web applications and frameworks are the primary consumers of templating languages, and the vast majority of templating languages were written with web use in mind. Except maybe string.Template, I can't think of ANY templating language not written with the web in mind. * Most templating languages are interfaced in very similar ways -- dict of variables in, string out. Despite the fact that these languages were written for the web, people still haven't felt a need to go beyond this. * But the exact details of invoking the template vary widely, in ways that are very annoying for people who want to support multiple languages. It is even very annoying for people who only want to support one language, because the interfaces often have several options and there's never been a particular target API for template language authors to shoot for. There's no best practice for this side of the API design. Thanks for confirming that I'm not entirely out of my mind. There's too much written here for me to respond on directly, but I like the way things are going -- genuine consideration of the complexity of the issues, and the desire to have an inclusive standard. I seem to accidentally have caused some confusion by writing how can it be considered a templating system if it has no access to request/response? -- Reading back I can't quite reconstruct what I *meant* to say, but it was more like the opposite -- e.g. how can you exclude templating systems that don't need access to request/response? My apologies. Phillip described the workflow for Django/Cheetah style templates as follows: * framework calls some Python code you wrote * your code returns a dictionary of values you want rendered * framework passes your returned values to the template, gets back a string * framework sends the string back to the browser But there's an even lower-level variant, where the Python code referenced invokes the template (with variables) and receives a string back, which it possibly munges further and then passes to the framework. (For example, my first attempt at using Django templates had one piece of Python code that concatenated the results from several templates.) I'd like someone to write up a similar list explaining how e.g. Zope3 differs -- I suppose at one point in the past I used to know, but that knowledge is on a back-up tape that was lost after I moved to California. :-( Phillip also wrote this: As Ben has previously pointed out, systems like Myghty are going to ignore your 'find_template()' because they do their own finding. So the spec will leak no matter what, until we get to the level of specification called for by the embedding side of my proposal. (The compile/write stuff.) And 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 (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
Re: [Web-SIG] A trivial template API counter-proposal
[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_stream read_compiled(input_stream) - read a template from input_stream and return a WSGI application object 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 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.5 standard library?) -- --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
