On Wed, Sep 9, 2009 at 12:52, David Shi wrote:
> What actions can I try to reduce the execution time?
This has absolutely nothing to do with the interests of the Web-SIG.
Please send more general Python questions to
http://mail.python.org/mailman/listinfo/python-list.
Cheers,
Dirkjan
__
On Tue, Mar 30, 2010 at 11:28, Manlio Perillo wrote:
> Note however, that Mercurial has fixed the problem:
So, as the guy who inherited Mercurial's hgweb WSGI application (or
rather, made it much more WSGI-compliant), I should say that, yes, I
tried pretty hard to get all our code so that it woul
On Tue, Mar 30, 2010 at 11:44, Manlio Perillo wrote:
> Did you managed to remove usage of the write callable?
Yes, I think we haven't been using that for a few versions now.
Cheers,
Dirkjan
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://w
On Sat, Apr 10, 2010 at 15:04, Chris Dent wrote:
> On Thu, 8 Apr 2010, P.J. Eby wrote:
>> This is also a good time for people to learn that generators are usually a
>> *very bad* way to write WSGI apps - yielding is for server push or sending
>> blocks of large files, not tiny strings. In general
On Tue, Apr 13, 2010 at 13:13, Graham Dumpleton
wrote:
> There is no such thing as a WSGI 2.0 PEP and there is no proper
> concensus either on what it should look like. Thus if you see anything
> claiming to implement WSGI 2.0, then it isn't and you should only view
> it as an experimental proposa
On Tue, Apr 13, 2010 at 13:39, Graham Dumpleton
wrote:
> WSGI 2.0 isn't about Python 3.X, it is about removing start_response().
Okay, so it is orthogonal, right?
> Python 3.X support can be catered for by clarifications in the WSGI
> 1.0 specification and to a degree how Python 3.X is implement
On Tue, Apr 13, 2010 at 14:01, Graham Dumpleton
wrote:
> They are not simplications. They are clarifications or just describing
> existing practice. They are not necessarily mod_wsgi specific.
Sorry, I didn't mean to imply they were mod_wsgi specific, and they
definitely look sane/like an improve
On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
wrote:
> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>
> And when I say 'last attempt', yes there have been people who have
> stepped up to try and get this to happen in the past. I think you
> would be the 3rd time, exclu
On Thu, Apr 15, 2010 at 01:35, Graham Dumpleton
wrote:
> If that isn't done, we will be here in another year still arguing
> about whether some aspect of the specification should be changed or
> removed based on some individuals perceived need.
I agree, WSGI 1.1 should be more like HTML5 in that
On Thu, Apr 15, 2010 at 11:09, Manlio Perillo wrote:
> Ehm, the purpose of WSGI 2.0 is precisely to remove start_response and
> write callable with it...
Right, there you go!
Cheers,
Dirkjan
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://
ay Interface 1.1
Version: $Revision$
Last-Modified: $Date$
-Author: Phillip J. Eby
+Author: Dirkjan Ochtman ,
+Graham Dumpleton
Discussions-To: Python Web-SIG
Status: Draft
Type: Informational
Content-Type: text/x-rst
-Created: 07-Dec-2003
-Post-History: 07-Dec-2003, 08-Aug-2004, 20-Aug-2
On Tue, Jul 6, 2010 at 12:50, Graham Dumpleton
wrote:
> In the code example I posted I never had a 'return' statement in same
> function as 'yield'. You shouldn't be mixing the two.
Well, you can still use bare "return" as a way of raising StopIteration.
Cheers,
Dirkjan
On Thu, Sep 16, 2010 at 01:03, Chris McDonough wrote:
> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI
On Thu, Sep 16, 2010 at 13:32, Armin Ronacher
wrote:
> The motivation is that you can pass that to constructors of response objects
> already in place.
>
> response_tuple = response.get_response_tuple()
> response = Response(*response_tuple)
>
> The order "body", "status code", "headers" is what W
On Thu, Sep 16, 2010 at 21:39, P.J. Eby wrote:
> Or, to put it another way: splitting the spec into two 100% incompatible
> versions is a bad idea for Python 3 adoption. With a WSGI 1 addendum, we
> should be able to make it possible to put the same apps and middleware on 2
> and 3 with just a de
On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins
wrote:
> Well, thats certainly a challenge :). Whats the governance model here?
> Is a PEP appropriate, and if so - that gives us a BFDL or BFDL
> PEP-delegate to decide between bikeshed issues; and if its not a
> bikeshed issue then resolving it is
On Fri, Sep 26, 2014 at 5:32 AM, Robert Collins
wrote:
> So I propose we drop the write callable, and include a queue based
> implementation in the adapter for PEP- code.
+1.
Cheers,
Dirkjan
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: htt
On Fri, Sep 26, 2014 at 6:14 AM, Robert Collins
wrote:
> I don't think we need read1 (perhaps I'm wrong) but making read
> consistent with the io library would be good, I think - particularly
> for websockets.
I would agree, but for websockets, I'd really want a per-frame
generator or something.
On Wed, Feb 17, 2016 at 12:51 PM, Cory Benfield wrote:
> Please let me know what you think!
I reviewed all the pull requests and they look good to me, save one
tiny nit that I left a comment for.
Cheers,
Dirkjan
___
Web-SIG mailing list
Web-SIG@python
2009/1/12 Girish Redekar :
> is still tedious as font sizes in html/css can be expressed in multiple
> methods (like tags, sizes in pixels, relative sizes, default larger
> size for header etc). One can get down and code each of these cases, but I
> was hoping someone has already (and reliably) wo
20 matches
Mail list logo