...
> It is all very silly. Technically a file like object is not
> required
> to have a 'closed' attribute, so that code expecting it was
> wrong in
> the first place.
> All you can really do is supply as many of the methods,
> attributes as
> possible, all required and as many as optional as
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
Dirkjan Ochtman ha scritto:
> 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),
Did you managed to remove usage of th
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
Graham Dumpleton ha scritto:
> [...]
>> Here is the culprit:
>> http://lists.alioth.debian.org/pipermail/python-modules-team/2009-January/003514.html
>> http://code.google.com/p/modwsgi/issues/detail?id=82
>>
>> So it seems safe, when the Log object used in wsgi.errors is also used
>> to replace s
On 30 March 2010 19:27, Manlio Perillo wrote:
> Manlio Perillo ha scritto:
>> Hi.
>>
>> Some time ago, someone reported me that an application embedded in Nginx
>> with my WSGI module failed to execute, since in my implementation the
>> wsgi.errors object does not implement the .close method.
>>
>
Manlio Perillo ha scritto:
> Hi.
>
> Some time ago, someone reported me that an application embedded in Nginx
> with my WSGI module failed to execute, since in my implementation the
> wsgi.errors object does not implement the .close method.
>
> [...]
> Any idea?
>
Here is the culprit:
http://li
Graham Dumpleton ha scritto:
> On 28 March 2010 22:21, Manlio Perillo wrote:
>> Graham Dumpleton ha scritto:
>>> [...]
Unfortunately I never got to know what application or framework was
causing the problem.
Any idea?
>> Sorry, my question was not clear.
>>
>> I was asking what
On 28 March 2010 22:21, Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
>> [...]
>>> Unfortunately I never got to know what application or framework was
>>> causing the problem.
>>>
>>> Any idea?
>>
>
> Sorry, my question was not clear.
>
> I was asking what applications or frameworks call th
Graham Dumpleton ha scritto:
> [...]
>> Unfortunately I never got to know what application or framework was
>> causing the problem.
>>
>> Any idea?
>
Sorry, my question was not clear.
I was asking what applications or frameworks call the .close method on
the errors object.
I want to check if:
*
At 08:10 PM 3/27/2010 +0100, Manlio Perillo wrote:
Some time ago, someone reported me that an application embedded in Nginx
with my WSGI module failed to execute, since in my implementation the
wsgi.errors object does not implement the .close method.
We should probably note in the spec that WSG
On 28 March 2010 06:10, Manlio Perillo wrote:
> Hi.
>
> Some time ago, someone reported me that an application embedded in Nginx
> with my WSGI module failed to execute, since in my implementation the
> wsgi.errors object does not implement the .close method.
>
> The same object type is used to re
Hi.
Some time ago, someone reported me that an application embedded in Nginx
with my WSGI module failed to execute, since in my implementation the
wsgi.errors object does not implement the .close method.
The same object type is used to replace sys.stderr.
Of course, both trying to close wsgi.err
13 matches
Mail list logo
