From me at gustavonarea.net  Mon Mar  8 13:04:27 2010
From: me at gustavonarea.net (Gustavo Narea)
Date: Mon, 8 Mar 2010 12:04:27 +0000
Subject: [Web-SIG] ANN: twod.wsgi -- Better WSGI support for Django
Message-ID: <7022d0871003080404p4e6f581bn1b7aa6d634b1495c@mail.gmail.com>

Hello, everybody.

I'm very pleased to announce the first alpha release of twod.wsgi, a library
to make WSGI a first-class citizen in Django applications.

I believe it brings WSGI support in Django to the same level as in
frameworks like Pylons, or at least that's the goal. If you're missing
PasteDeploy or WebOb in Django, you'll love to know you can get them working
in your existing application very easily.

Here's the Web site:
http://packages.python.org/twod.wsgi/

Cheers,

 - Gustavo.
http://dev.2degreesnetwork.com

PS: I'll be cross-posting this announcement in some relevant mailing lists,
so I'm sorry if you receive this multiple times! I won't do it again, so you
may want to keep an eye on our blog if you're interested in twod.wsgi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100308/3a0d953a/attachment.html>

From kiorky at cryptelium.net  Sun Mar 14 15:16:01 2010
From: kiorky at cryptelium.net (kiorky)
Date: Sun, 14 Mar 2010 15:16:01 +0100
Subject: [Web-SIG] ANN: twod.wsgi -- Better WSGI support for Django
In-Reply-To: <7022d0871003080404p4e6f581bn1b7aa6d634b1495c@mail.gmail.com>
References: <7022d0871003080404p4e6f581bn1b7aa6d634b1495c@mail.gmail.com>
Message-ID: <4B9CEFA1.5030409@cryptelium.net>

Toward the PythonPaste support, i made some times ago something that already do
all of that and even more (like more that one django app sharing the same paste
configuration).

It's called dj.paste [1].

[1] - http://pypi.python.org/pypi/dj.paste

Le 08/03/2010 13:04, Gustavo Narea a ?crit :
> Hello, everybody.
> 
> I'm very pleased to announce the first alpha release of twod.wsgi, a
> library to make WSGI a first-class citizen in Django applications.
> 
> I believe it brings WSGI support in Django to the same level as in
> frameworks like Pylons, or at least that's the goal. If you're missing
> PasteDeploy or WebOb in Django, you'll love to know you can get them
> working in your existing application very easily.
> 
> Here's the Web site:
> http://packages.python.org/twod.wsgi/
> 
> Cheers,
> 
>  - Gustavo.
> http://dev.2degreesnetwork.com
> 
> PS: I'll be cross-posting this announcement in some relevant mailing
> lists, so I'm sorry if you receive this multiple times! I won't do it
> again, so you may want to keep an eye on our blog if you're interested
> in twod.wsgi.
> 
> 
> 
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/kiorky%40cryptelium.net

-- 
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100314/73517478/attachment.pgp>

From gael at gawel.org  Sun Mar 14 15:36:27 2010
From: gael at gawel.org (Gael Pasgrimaud)
Date: Sun, 14 Mar 2010 15:36:27 +0100
Subject: [Web-SIG] ANN: twod.wsgi -- Better WSGI support for Django
In-Reply-To: <4B9CEFA1.5030409@cryptelium.net>
References: <7022d0871003080404p4e6f581bn1b7aa6d634b1495c@mail.gmail.com>
	<4B9CEFA1.5030409@cryptelium.net>
Message-ID: <7911b3bb1003140736u6db4960m6a3880a8a48e83a9@mail.gmail.com>

On Sun, Mar 14, 2010 at 3:16 PM, kiorky <kiorky at cryptelium.net> wrote:
> Toward the PythonPaste support, i made some times ago something that already do
> all of that and even more (like more that one django app sharing the same paste
> configuration).
>

You mean you also patch django's request with webob ?
Look like your egg is only a paste factory for django.

twod.wsgi do more. like adding views methods, allow to set
settings.py's attributes etc.

> It's called dj.paste [1].
>
> [1] - http://pypi.python.org/pypi/dj.paste
>
> Le 08/03/2010 13:04, Gustavo Narea a ?crit :
>> Hello, everybody.
>>
>> I'm very pleased to announce the first alpha release of twod.wsgi, a
>> library to make WSGI a first-class citizen in Django applications.
>>
>> I believe it brings WSGI support in Django to the same level as in
>> frameworks like Pylons, or at least that's the goal. If you're missing
>> PasteDeploy or WebOb in Django, you'll love to know you can get them
>> working in your existing application very easily.
>>
>> Here's the Web site:
>> http://packages.python.org/twod.wsgi/
>>
>> Cheers,
>>
>> ?- Gustavo.
>> http://dev.2degreesnetwork.com
>>
>> PS: I'll be cross-posting this announcement in some relevant mailing
>> lists, so I'm sorry if you receive this multiple times! I won't do it
>> again, so you may want to keep an eye on our blog if you're interested
>> in twod.wsgi.
>>
>>
>>
>> _______________________________________________
>> Web-SIG mailing list
>> Web-SIG at python.org
>> Web SIG: http://www.python.org/sigs/web-sig
>> Unsubscribe: http://mail.python.org/mailman/options/web-sig/kiorky%40cryptelium.net
>
> --
> Cordialement,
> KiOrKY
> GPG Key FingerPrint: 0x1A1194B7681112AF
>
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/gael%40gawel.org
>
>

From kiorky at cryptelium.net  Sun Mar 14 16:08:59 2010
From: kiorky at cryptelium.net (kiorky)
Date: Sun, 14 Mar 2010 16:08:59 +0100
Subject: [Web-SIG] ANN: twod.wsgi -- Better WSGI support for Django
In-Reply-To: <7911b3bb1003140736u6db4960m6a3880a8a48e83a9@mail.gmail.com>
References: <7022d0871003080404p4e6f581bn1b7aa6d634b1495c@mail.gmail.com>	
	<4B9CEFA1.5030409@cryptelium.net>
	<7911b3bb1003140736u6db4960m6a3880a8a48e83a9@mail.gmail.com>
Message-ID: <4B9CFC0B.1050802@cryptelium.net>


Le 14/03/2010 15:36, Gael Pasgrimaud a ?crit :
> On Sun, Mar 14, 2010 at 3:16 PM, kiorky <kiorky at cryptelium.net> wrote:
>> Toward the PythonPaste support, i made some times ago something that already do
>> all of that and even more (like more that one django app sharing the same paste
>> configuration).
>>
> 
> You mean you also patch django's request with webob ?
Yes.

> Look like your egg is only a paste factory for django.
Yes, as i said previously but it was maybe unclear.
It only contains 2 applications factories (mono or multi django mode).

> 
> twod.wsgi do more. like adding views methods, allow to set
> settings.py's attributes etc.
Ok.
You can only set an arbitrary django settings module per application with dj.paste.

-- 
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100314/b59a3f87/attachment.pgp>

From me at gustavonarea.net  Mon Mar 15 15:12:00 2010
From: me at gustavonarea.net (Gustavo Narea)
Date: Mon, 15 Mar 2010 14:12:00 +0000
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
Message-ID: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>

Hello,

We're considering migrating from mod_wsgi to FastCGI (Apache) because we'll
need to use versions of Python compiled by ourselves.

In addition to the research I've done and the pre-deployment tests we'll
carry out, I'd love to know if any of you has done the same migration. If
so, how was this experience? I suspect there's nothing to worry about
(that's what WSGI is for), but just in case...

Thanks,

 - Gustavo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100315/99a587d1/attachment.html>

From manlio_perillo at libero.it  Mon Mar 15 15:47:12 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Mon, 15 Mar 2010 15:47:12 +0100
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
In-Reply-To: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
References: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
Message-ID: <4B9E4870.5050300@libero.it>

Gustavo Narea ha scritto:
> Hello,
> 
> We're considering migrating from mod_wsgi to FastCGI (Apache) because
> we'll need to use versions of Python compiled by ourselves.
> 

Note that you can simply recompile mod_wsgi to use your custom Python.

> [...]


Manlio

From bchesneau at gmail.com  Mon Mar 15 16:02:25 2010
From: bchesneau at gmail.com (Benoit Chesneau)
Date: Mon, 15 Mar 2010 16:02:25 +0100
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
In-Reply-To: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
References: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
Message-ID: <b7cd8ed11003150802g7cffc53j73f8a9f7dfbe4cb5@mail.gmail.com>

On Mon, Mar 15, 2010 at 3:12 PM, Gustavo Narea <me at gustavonarea.net> wrote:
> Hello,
>
> We're considering migrating from mod_wsgi to FastCGI (Apache) because we'll
> need to use versions of Python compiled by ourselves.
>
> In addition to the research I've done and the pre-deployment tests we'll
> carry out, I'd love to know if any of you has done the same migration. If
> so, how was this experience? I suspect there's nothing to worry about
> (that's what WSGI is for), but just in case...
>
> Thanks,
>
> ?- Gustavo.
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com
>
>

why not just use a gateway behind a proxy ?

- benoit

From me at gustavonarea.net  Mon Mar 15 17:54:53 2010
From: me at gustavonarea.net (Gustavo Narea)
Date: Mon, 15 Mar 2010 16:54:53 +0000
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
In-Reply-To: <4B9E4870.5050300@libero.it>
References: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
	<4B9E4870.5050300@libero.it>
Message-ID: <7022d0871003150954u65e20864ifb34fdaec2ab2031@mail.gmail.com>

On Mon, Mar 15, 2010 at 2:47 PM, Manlio Perillo <manlio_perillo at libero.it>wrote:

> Note that you can simply recompile mod_wsgi to use your custom Python.
>

We may need to use different versions of Python. :/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100315/c821473b/attachment.html>

From nathan at yergler.net  Mon Mar 15 18:02:28 2010
From: nathan at yergler.net (Nathan Yergler)
Date: Mon, 15 Mar 2010 10:02:28 -0700
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
In-Reply-To: <7022d0871003150954u65e20864ifb34fdaec2ab2031@mail.gmail.com>
References: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com> 
	<4B9E4870.5050300@libero.it>
	<7022d0871003150954u65e20864ifb34fdaec2ab2031@mail.gmail.com>
Message-ID: <53039e7b1003151002o63b0678aob53048d444ff22a2@mail.gmail.com>

We've migrated a couple applications from mod_wsgi to mod_fcgid
(http://httpd.apache.org/mod_fcgid/) without any problems, and it's
now our default deployment strategy.

Regards,

Nathan


On Mon, Mar 15, 2010 at 9:54 AM, Gustavo Narea <me at gustavonarea.net> wrote:
> On Mon, Mar 15, 2010 at 2:47 PM, Manlio Perillo <manlio_perillo at libero.it>
> wrote:
>>
>> Note that you can simply recompile mod_wsgi to use your custom Python.
>
> We may need to use different versions of Python. :/
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/nathan%40yergler.net
>
>

From kiorky at cryptelium.net  Mon Mar 15 23:05:54 2010
From: kiorky at cryptelium.net (kiorky)
Date: Mon, 15 Mar 2010 23:05:54 +0100
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
In-Reply-To: <b7cd8ed11003150802g7cffc53j73f8a9f7dfbe4cb5@mail.gmail.com>
References: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
	<b7cd8ed11003150802g7cffc53j73f8a9f7dfbe4cb5@mail.gmail.com>
Message-ID: <4B9EAF42.6080504@cryptelium.net>

Le 15/03/2010 16:02, Benoit Chesneau a ?crit :
> On Mon, Mar 15, 2010 at 3:12 PM, Gustavo Narea <me at gustavonarea.net> wrote:


> why not just use a gateway behind a proxy ?
That could be what i would have done too.


> - benoit

-- 
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100315/f5c222e8/attachment.pgp>

From alex at grep.ro  Tue Mar 16 16:35:29 2010
From: alex at grep.ro (Alex Morega)
Date: Tue, 16 Mar 2010 16:35:29 +0100
Subject: [Web-SIG] Generic configuration
Message-ID: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>

Hello,

This is not really a WSGI question, it's more into general configuration, but I don't know of a better place to ask it.

Paster config files allow you to hook up WSGI applications, middleware, and a server, plus some (undocumented?) magic configuration of the logging module. But what about random components, like a database? Ideally I'd like to specify a factory for database connections and give it some parameters; this would return a reference to a new database connection. I could then pass this reference to my wsgi app or middleware.

Apparently the pattern is to perform this database configuration as part of a wsgi middleware, but that feels unnatural. Or one could do this outside of the paste configuration file, but that just splits the configuration needlessly into several pieces. Am I missing something obvious?

Thanks,
-- Alex


From arw1961 at yahoo.com  Tue Mar 16 20:47:43 2010
From: arw1961 at yahoo.com (Aaron Watters)
Date: Tue, 16 Mar 2010 12:47:43 -0700 (PDT)
Subject: [Web-SIG] Generic configuration
In-Reply-To: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
Message-ID: <289576.16554.qm@web111717.mail.gq1.yahoo.com>

WHIFF has a concept of configurable resources
for application groups, if you care to take a look.

concept: 
  http://whiffdoc.appspot.com/docs/W1000_1000.resources
deployment API: 
  http://whiffdoc.appspot.com/docs/W1200_1000.DirectoryConfig
access API:
  http://whiffdoc.appspot.com/docs/W1200_1300.applicationAPI#Header8
example usage: 
  http://whiffdoc.appspot.com/docs/W1100_1200.wwiki#Header7

I'm currently extending this paradigm to allow resource
allocation with access control support.
That should be in the next release.

   -- Aaron Watters

--- On Tue, 3/16/10, Alex Morega <alex at grep.ro> wrote:

> From: Alex Morega <alex at grep.ro>
> Subject: [Web-SIG] Generic configuration
> To: web-sig at python.org
> Date: Tuesday, March 16, 2010, 11:35 AM
> Hello,
> 
> This is not really a WSGI question, it's more into general
> configuration, but I don't know of a better place to ask
> it.
> 
> Paster config files allow you to hook up WSGI applications,
> middleware, and a server, plus some (undocumented?) magic
> configuration of the logging module. But what about random
> components, like a database? Ideally I'd like to specify a
> factory for database connections and give it some
> parameters; this would return a reference to a new database
> connection. I could then pass this reference to my wsgi app
> or middleware.
> 
> Apparently the pattern is to perform this database
> configuration as part of a wsgi middleware, but that feels
> unnatural. Or one could do this outside of the paste
> configuration file, but that just splits the configuration
> needlessly into several pieces. Am I missing something
> obvious?
> 
> Thanks,
> -- Alex
> 
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/arw1961%40yahoo.com
> 

From me at gustavonarea.net  Tue Mar 16 21:54:14 2010
From: me at gustavonarea.net (Gustavo Narea)
Date: Tue, 16 Mar 2010 20:54:14 +0000
Subject: [Web-SIG] Migrating from mod_wsgi to FastCGI
In-Reply-To: <53039e7b1003151002o63b0678aob53048d444ff22a2@mail.gmail.com>
References: <7022d0871003150712l5af42d7bqe4518bafeab7b6c@mail.gmail.com>
	<4B9E4870.5050300@libero.it>
	<7022d0871003150954u65e20864ifb34fdaec2ab2031@mail.gmail.com>
	<53039e7b1003151002o63b0678aob53048d444ff22a2@mail.gmail.com>
Message-ID: <4B9FEFF6.7010608@gustavonarea.net>

Thank you all for your responses!

 - Gustavo.

On 15/03/10 17:02, Nathan Yergler wrote:
> We've migrated a couple applications from mod_wsgi to mod_fcgid
> (http://httpd.apache.org/mod_fcgid/) without any problems, and it's
> now our default deployment strategy.
>
> Regards,
>
> Nathan
>
>
> On Mon, Mar 15, 2010 at 9:54 AM, Gustavo Narea <me at gustavonarea.net> wrote:
>   
>> On Mon, Mar 15, 2010 at 2:47 PM, Manlio Perillo <manlio_perillo at libero.it>
>> wrote:
>>     
>>> Note that you can simply recompile mod_wsgi to use your custom Python.
>>>       
>> We may need to use different versions of Python. :/
>>
>> _______________________________________________
>> Web-SIG mailing list
>> Web-SIG at python.org
>> Web SIG: http://www.python.org/sigs/web-sig
>> Unsubscribe:
>> http://mail.python.org/mailman/options/web-sig/nathan%40yergler.net
>>
>>
>>     


-- 
Gustavo Narea <xri://=Gustavo>.


From manlio_perillo at libero.it  Wed Mar 17 00:24:54 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed, 17 Mar 2010 00:24:54 +0100
Subject: [Web-SIG] Generic configuration
In-Reply-To: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
References: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
Message-ID: <4BA01346.70203@libero.it>

Alex Morega ha scritto:
> Hello,
> 
> This is not really a WSGI question, it's more into general configuration, but I don't know of a better place to ask it.
> 
> Paster config files allow you to hook up WSGI applications, middleware, and a server, plus some (undocumented?) magic configuration of the logging module. But what about random components, like a database? Ideally I'd like to specify a factory for database connections and give it some parameters; this would return a reference to a new database connection. I could then pass this reference to my wsgi app or middleware.
> 
> Apparently the pattern is to perform this database configuration as part of a wsgi middleware, but that feels unnatural. Or one could do this outside of the paste configuration file, but that just splits the configuration needlessly into several pieces. Am I missing something obvious?
> 

I use YAML with custom constructors:
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/loader.py

There is a middleware:
  http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/middleware.py
that reads a list of configuration files to load from the WSGI environ
(I set this in the Nginx mod_wsgi) configuration, and merge all the
configuration in the WSGI environ.

Using custom YAML constructors it is possible to do something like:
  http://hg.mperillo.ath.cx/wsgix/examples/file/tip/dbview/settings.yml

It is also possible to configure the global python logging, create
temporary files and so on.


> Thanks,
> -- Alex
> 


Manlio

From alex at grep.ro  Wed Mar 17 10:51:05 2010
From: alex at grep.ro (Alex Morega)
Date: Wed, 17 Mar 2010 10:51:05 +0100
Subject: [Web-SIG] Generic configuration
In-Reply-To: <4BA01346.70203@libero.it>
References: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
	<4BA01346.70203@libero.it>
Message-ID: <1FD9623C-4A56-478A-92E7-812936CE0381@grep.ro>


On 17 Mar 2010, at 0:24, Manlio Perillo wrote:

> Alex Morega ha scritto:
>> Hello,
>> 
>> This is not really a WSGI question, it's more into general configuration, but I don't know of a better place to ask it.
>> 
>> Paster config files allow you to hook up WSGI applications, middleware, and a server, plus some (undocumented?) magic configuration of the logging module. But what about random components, like a database? Ideally I'd like to specify a factory for database connections and give it some parameters; this would return a reference to a new database connection. I could then pass this reference to my wsgi app or middleware.
>> 
>> Apparently the pattern is to perform this database configuration as part of a wsgi middleware, but that feels unnatural. Or one could do this outside of the paste configuration file, but that just splits the configuration needlessly into several pieces. Am I missing something obvious?
>> 
> 
> I use YAML with custom constructors:
> http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/loader.py
> 
> There is a middleware:
>  http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/middleware.py
> that reads a list of configuration files to load from the WSGI environ
> (I set this in the Nginx mod_wsgi) configuration, and merge all the
> configuration in the WSGI environ.
> 
> Using custom YAML constructors it is possible to do something like:
>  http://hg.mperillo.ath.cx/wsgix/examples/file/tip/dbview/settings.yml
> 
> It is also possible to configure the global python logging, create
> temporary files and so on.

That's still configuring a piece of WSGI middleware or application. I'm thinking about something along these lines:

=========================
[daemon]
factory = egg:PasteScript#wsgiutils
host = 127.0.0.1
port = 8000
app = my_site

[my_site]
factory = egg:Paste#composite
urlmap = my_urlmap

[my_urlmap]
factory = egg:Paste#urlmap
/blog = blog_app
/media = media_app

[media_app]
factory = egg:Paste#static
document_root = %(here)s/static_media

[blog_app]
factory = python:my.package.blog:app_factory
db = my_db

[my_db]
factory = python:my.package.db:conenction_factory
host = localhost
port = 3333
=========================

Every section has a factory (in the same way every section in Paste config files has "use=" and every part in buildout has "recipe="); the factories get called with the rest of the parameters from their section, using e.g. keyword arguments. The goal is to configure components independently, and tie them together into an application/service/daemon/whatever. Only the "daemon" and "factory" names have magical meaning, everything else is either looked up, or sent as a parameter string.

As far as I'm aware, it's somewhat possible to do this from within a framework, using a predefined set of pieces; I'd like to use arbitrary factories and entry points.

Cheers,
-- Alex


From manlio_perillo at libero.it  Wed Mar 17 13:47:09 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Wed, 17 Mar 2010 13:47:09 +0100
Subject: [Web-SIG] Generic configuration
In-Reply-To: <1FD9623C-4A56-478A-92E7-812936CE0381@grep.ro>
References: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
	<4BA01346.70203@libero.it>
	<1FD9623C-4A56-478A-92E7-812936CE0381@grep.ro>
Message-ID: <4BA0CF4D.4050507@libero.it>

Alex Morega ha scritto:
> On 17 Mar 2010, at 0:24, Manlio Perillo wrote:
> 
>> Alex Morega ha scritto:
>>> Hello,
>>>
>>> This is not really a WSGI question, it's more into general configuration, but I don't know of a better place to ask it.
>>>
> [...]
>> I use YAML with custom constructors:
>> http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/loader.py
>>
>> There is a middleware:
>>  http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/middleware.py
>> that reads a list of configuration files to load from the WSGI environ
>> (I set this in the Nginx mod_wsgi) configuration, and merge all the
>> configuration in the WSGI environ.
>>
>> Using custom YAML constructors it is possible to do something like:
>>  http://hg.mperillo.ath.cx/wsgix/examples/file/tip/dbview/settings.yml
>>
> [...]
> 
> That's still configuring a piece of WSGI middleware or application. I'm thinking about something along these lines:
> 

Yes, since it works quite differently from other frameworks.

Middleware are very easy to configure; in Nginx configuration file:
   wsgi_middleware wsgix.conf.middleware;


The reason is that how you want to store configuration parameters should
not hard written in the framework.
Using YAML in my framework does not prevent using other methods like
ConfigParser or Python modules.

> =========================
> [daemon]
> factory = egg:PasteScript#wsgiutils
> host = 127.0.0.1
> port = 8000
> app = my_site
>
> [...]
>

If you want this, isn't it more simple and generic to use YAML?


Manlio

From alex at grep.ro  Thu Mar 18 10:10:30 2010
From: alex at grep.ro (Alex Morega)
Date: Thu, 18 Mar 2010 10:10:30 +0100
Subject: [Web-SIG] Generic configuration
In-Reply-To: <4BA0CF4D.4050507@libero.it>
References: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
	<4BA01346.70203@libero.it>
	<1FD9623C-4A56-478A-92E7-812936CE0381@grep.ro>
	<4BA0CF4D.4050507@libero.it>
Message-ID: <1D208D0F-2F70-4E8B-A4AE-F916EF700304@grep.ro>


On 17 Mar 2010, at 13:47, Manlio Perillo wrote:

> Alex Morega ha scritto:
>> On 17 Mar 2010, at 0:24, Manlio Perillo wrote:
>> 
>>> Alex Morega ha scritto:
>>>> Hello,
>>>> 
>>>> This is not really a WSGI question, it's more into general configuration, but I don't know of a better place to ask it.
>>>> 
>> [...]
>>> I use YAML with custom constructors:
>>> http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/loader.py
>>> 
>>> There is a middleware:
>>> http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/conf/middleware.py
>>> that reads a list of configuration files to load from the WSGI environ
>>> (I set this in the Nginx mod_wsgi) configuration, and merge all the
>>> configuration in the WSGI environ.
>>> 
>>> Using custom YAML constructors it is possible to do something like:
>>> http://hg.mperillo.ath.cx/wsgix/examples/file/tip/dbview/settings.yml
>>> 
>> [...]
>> 
>> That's still configuring a piece of WSGI middleware or application. I'm thinking about something along these lines:
>> 
> 
> Yes, since it works quite differently from other frameworks.
> 
> Middleware are very easy to configure; in Nginx configuration file:
>   wsgi_middleware wsgix.conf.middleware;
> 
> 
> The reason is that how you want to store configuration parameters should
> not hard written in the framework.
> Using YAML in my framework does not prevent using other methods like
> ConfigParser or Python modules.
> 
>> =========================
>> [daemon]
>> factory = egg:PasteScript#wsgiutils
>> host = 127.0.0.1
>> port = 8000
>> app = my_site
>> 
>> [...]
>> 
> 
> If you want this, isn't it more simple and generic to use YAML?

Yaml buys you flexibility at the cost of readability, which might be a good trade-off, but that's not the point. You still need a tool that reads the configuration file and does the actual setup.

Does the wsgix configuration loader allow for plugins, i.e. defining my own constructors? Is it documented?

I chose to base my example on Paster configuration because it already knows about egg entry points and explicitly pointing to factory functions.

Cheers,
-- Alex


From manlio_perillo at libero.it  Thu Mar 18 11:12:15 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Thu, 18 Mar 2010 11:12:15 +0100
Subject: [Web-SIG] Generic configuration
In-Reply-To: <1D208D0F-2F70-4E8B-A4AE-F916EF700304@grep.ro>
References: <D4274F3E-EACF-42B0-BC70-D8A8552F6DC8@grep.ro>
	<4BA01346.70203@libero.it>
	<1FD9623C-4A56-478A-92E7-812936CE0381@grep.ro>
	<4BA0CF4D.4050507@libero.it>
	<1D208D0F-2F70-4E8B-A4AE-F916EF700304@grep.ro>
Message-ID: <4BA1FC7F.20203@libero.it>

Alex Morega ha scritto:
> On 17 Mar 2010, at 13:47, Manlio Perillo wrote:
> [...]
>>> =========================
>>> [daemon]
>>> factory = egg:PasteScript#wsgiutils
>>> host = 127.0.0.1
>>> port = 8000
>>> app = my_site
>>>
>>> [...]
>>>
>> If you want this, isn't it more simple and generic to use YAML?
> 
> Yaml buys you flexibility at the cost of readability, which might be a good trade-off, but that's not the point. You still need a tool that reads the configuration file and does the actual setup.
> 
> Does the wsgix configuration loader allow for plugins, i.e. defining my own constructors? Is it documented?
> 

This is a non problem.

You can write your own YAML loader (maybe deriving it from the existing
one), write a small middleware that use this loader and push it into the
stack middleware.

There is no need to support generic plugins.

> I chose to base my example on Paster configuration because it already knows about egg entry points and explicitly pointing to factory functions.
> 


Manlio

From manlio_perillo at libero.it  Sat Mar 27 20:10:15 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Sat, 27 Mar 2010 20:10:15 +0100
Subject: [Web-SIG] wsgi.errors and close method
Message-ID: <4BAE5817.307@libero.it>

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.errors and sys.stderr means an
application/framework is broken, IMHO.

Unfortunately I never got to know what application or framework was
causing the problem.

Any idea?


Thanks  Manlio

From graham.dumpleton at gmail.com  Sun Mar 28 03:10:15 2010
From: graham.dumpleton at gmail.com (Graham Dumpleton)
Date: Sun, 28 Mar 2010 12:10:15 +1100
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BAE5817.307@libero.it>
References: <4BAE5817.307@libero.it>
Message-ID: <88e286471003271810w61199c64oa2d5fd5887775ca8@mail.gmail.com>

On 28 March 2010 06:10, Manlio Perillo <manlio_perillo at libero.it> 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 replace sys.stderr.
>
> Of course, both trying to close wsgi.errors and sys.stderr means an
> application/framework is broken, IMHO.

I'd agree, but there isn't much you can do about people/code not doing
the right thing. I had to give up on trying to get people to write
portable WSGI code and not arbitrarily try and read from or write to
sys.stdin and sys.stdout. It is a similar issue with things like
close() and various other methods that sys.stderr may supply. You just
have to provide a complete file like object implementation per Python
documentation requirements and have it appear that it did what was
requested and/or return an appropriate result for your system.

> Unfortunately I never got to know what application or framework was
> causing the problem.
>
> Any idea?

Looking at code, seems that for Apache/mod_wsgi I will notionally
close the log object, which means that if that did this for sys.stderr
standin, that any subsequent writes would result in a specific error
message to highlight that something wrong was done.

FWIW, the full set of methods and attributes I implement to make it
properly file like are:

static PyMethodDef Log_methods[] = {
    { "flush",      (PyCFunction)Log_flush,      METH_VARARGS, 0 },
    { "close",      (PyCFunction)Log_close,      METH_VARARGS, 0 },
    { "write",      (PyCFunction)Log_write,      METH_VARARGS, 0 },
    { "writelines", (PyCFunction)Log_writelines, METH_VARARGS, 0 },
#if PY_MAJOR_VERSION >= 3
    { "readable",   (PyCFunction)Log_readable,   METH_VARARGS, 0 },
    { "seekable",   (PyCFunction)Log_seekable,   METH_VARARGS, 0 },
    { "writable",   (PyCFunction)Log_writable,   METH_VARARGS, 0 },
#endif
    { NULL, NULL}
};

static PyGetSetDef Log_getset[] = {
    { "closed", (getter)Log_closed, NULL, 0 },
#if PY_MAJOR_VERSION < 3
    { "softspace", (getter)Log_get_softspace, (setter)Log_set_softspace, 0 },
#else
    { "encoding", (getter)Log_get_encoding, NULL, 0 },
    { "errors", (getter)Log_get_errors, NULL, 0 },
#endif
    { NULL },
};


Graham

From pje at telecommunity.com  Sun Mar 28 05:17:13 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 27 Mar 2010 23:17:13 -0400
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BAE5817.307@libero.it>
References: <4BAE5817.307@libero.it>
Message-ID: <20100328031712.567F03A4080@sparrow.telecommunity.com>

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 WSGI applications have no 
business closing the errors object; ISTM it is a completely meaningless action.


From manlio_perillo at libero.it  Sun Mar 28 13:21:30 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Sun, 28 Mar 2010 13:21:30 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <88e286471003271810w61199c64oa2d5fd5887775ca8@mail.gmail.com>
References: <4BAE5817.307@libero.it>
	<88e286471003271810w61199c64oa2d5fd5887775ca8@mail.gmail.com>
Message-ID: <4BAF3BBA.4010802@libero.it>

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:
* they are really calling the .close method on wsgi.errors, and why
* they are calling the .close method on stderr, and why


> [...]
> static PyGetSetDef Log_getset[] = {
>     { "closed", (getter)Log_closed, NULL, 0 },
> #if PY_MAJOR_VERSION < 3
>     { "softspace", (getter)Log_get_softspace, (setter)Log_set_softspace, 0 },
> #else

I noted that you added softspace descriptor in recent versions.
What is its purpose?
Is it here just for compatibility?



Thanks   Manlio

From graham.dumpleton at gmail.com  Sun Mar 28 13:49:59 2010
From: graham.dumpleton at gmail.com (Graham Dumpleton)
Date: Sun, 28 Mar 2010 22:49:59 +1100
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BAF3BBA.4010802@libero.it>
References: <4BAE5817.307@libero.it>
	<88e286471003271810w61199c64oa2d5fd5887775ca8@mail.gmail.com>
	<4BAF3BBA.4010802@libero.it>
Message-ID: <88e286471003280449l4229e42cv669b7a302c699e12@mail.gmail.com>

On 28 March 2010 22:21, Manlio Perillo <manlio_perillo at libero.it> 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 the .close method on
> the errors object.

I know what you were asking. My point was that it doesn't help to find
out as nearly impossible to get them to change the code. I have tried
that with a few different packages where there use of sys.stdin and
sys.stdout was questionable within context of WSGI. It is a loosing
battle. You just need to make your code tolerant to such possible
abuses.

> I want to check if:
> * they are really calling the .close method on wsgi.errors, and why
> * they are calling the .close method on stderr, and why
>
>
>> [...]
>> static PyGetSetDef Log_getset[] = {
>> ? ? { "closed", (getter)Log_closed, NULL, 0 },
>> #if PY_MAJOR_VERSION < 3
>> ? ? { "softspace", (getter)Log_get_softspace, (setter)Log_set_softspace, 0 },
>> #else
>
> I noted that you added softspace descriptor in recent versions.
> What is its purpose?
> Is it here just for compatibility?

It is related to how comma separated lists and comma at end of line is
used in the following.

  print >> sys.stderr, "a", "b",
  print >> sys.stderr, "c"

>From memory with out softspace attribute you will not get spaces
between things when using that syntax for output formatting.

I can't remember exact details and don't have time right now to see if
I had an issue in bug tracker about it or how much I documented it in
change files.

Graham

From manlio_perillo at libero.it  Sun Mar 28 14:06:35 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Sun, 28 Mar 2010 14:06:35 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <88e286471003280449l4229e42cv669b7a302c699e12@mail.gmail.com>
References: <4BAE5817.307@libero.it>	
	<88e286471003271810w61199c64oa2d5fd5887775ca8@mail.gmail.com>	
	<4BAF3BBA.4010802@libero.it>
	<88e286471003280449l4229e42cv669b7a302c699e12@mail.gmail.com>
Message-ID: <4BAF464B.4010109@libero.it>

Graham Dumpleton ha scritto:
> On 28 March 2010 22:21, Manlio Perillo <manlio_perillo at libero.it> 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 the .close method on
>> the errors object.
> 
> I know what you were asking. My point was that it doesn't help to find
> out as nearly impossible to get them to change the code. 

Ok, thanks.

My point is that I don't have strict compatibility requirements for my
ngx_http_wsgi_module, as you have with Apache mod_wsgi.

As an example, the other day I removed support for CPython
subinterpreters, since they make code more complex as it should be.

The reason I want to know the "bad" applications/framework is because I
would like to see the reason why they are calling the .close method.

[...]
>>> static PyGetSetDef Log_getset[] = {
>>>     { "closed", (getter)Log_closed, NULL, 0 },
>>> #if PY_MAJOR_VERSION < 3
>>>     { "softspace", (getter)Log_get_softspace, (setter)Log_set_softspace, 0 },
>>> #else
>> I noted that you added softspace descriptor in recent versions.
>> What is its purpose?
>> Is it here just for compatibility?
> 
> It is related to how comma separated lists and comma at end of line is
> used in the following.
> 
>   print >> sys.stderr, "a", "b",
>   print >> sys.stderr, "c"
> 

I will check it with my module, thanks.


Regards  Manlio

From manlio_perillo at libero.it  Tue Mar 30 10:27:17 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Tue, 30 Mar 2010 10:27:17 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BAE5817.307@libero.it>
References: <4BAE5817.307@libero.it>
Message-ID: <4BB1B5E5.7010203@libero.it>

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://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 sys.stderr, to just add the closed attribute (but *not* the
close method).


Thanks  Manlio

From graham.dumpleton at gmail.com  Tue Mar 30 11:06:03 2010
From: graham.dumpleton at gmail.com (Graham Dumpleton)
Date: Tue, 30 Mar 2010 20:06:03 +1100
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BB1B5E5.7010203@libero.it>
References: <4BAE5817.307@libero.it> <4BB1B5E5.7010203@libero.it>
Message-ID: <88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com>

On 30 March 2010 19:27, Manlio Perillo <manlio_perillo at libero.it> 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.
>>
>> [...]
>> Any idea?
>>
>
> 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 sys.stderr, to just add the closed attribute (but *not* the
> close method).

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.

  http://docs.python.org/library/stdtypes.html#file-objects

The close() method is however required of file like objects so if you
are going to replace a file like object, you should have it.

All you can really do is supply as many of the methods, attributes as
possible, all required and as many as optional as makes sense, because
you can't trust people to read the documentation properly.

Graham

From manlio_perillo at libero.it  Tue Mar 30 11:28:07 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Tue, 30 Mar 2010 11:28:07 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com>
References: <4BAE5817.307@libero.it> <4BB1B5E5.7010203@libero.it>
	<88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com>
Message-ID: <4BB1C427.8000708@libero.it>

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 sys.stderr, to just add the closed attribute (but *not* the
>> close method).
> 
> 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.
> 
>   http://docs.python.org/library/stdtypes.html#file-objects
> 

Right, thanks; I did not notice it.

Note however, that Mercurial has fixed the problem:

# stderr may be buffered under win32 when redirected to files,
# including stdout.
if not getattr(sys.stderr, 'closed', False):
    sys.stderr.flush()


I would probably do something like:
try:
    sys.stderr.flush()
except:
    pass


> The close() method is however required of file like objects so if you
> are going to replace a file like object, you should have it.
> 

Yes, I should.
But since they should raise an exception, raising AttributeError,
instead, should not be a critical problem.


Manlio

From dirkjan at ochtman.nl  Tue Mar 30 11:39:41 2010
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 30 Mar 2010 11:39:41 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BB1C427.8000708@libero.it>
References: <4BAE5817.307@libero.it> <4BB1B5E5.7010203@libero.it> 
	<88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com> 
	<4BB1C427.8000708@libero.it>
Message-ID: <ea2499da1003300239k135ae3d0k5c25a38149905db4@mail.gmail.com>

On Tue, Mar 30, 2010 at 11:28, Manlio Perillo <manlio_perillo at libero.it> 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 wouldn't touch
sys.std{in,out,err}. Unfortunately, since much of our code is built
primarily on the assumption that it runs on the command-line, it turns
out to be quite hard to get everything clean.

Cheers,

Dirkjan

From manlio_perillo at libero.it  Tue Mar 30 11:44:26 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Tue, 30 Mar 2010 11:44:26 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <ea2499da1003300239k135ae3d0k5c25a38149905db4@mail.gmail.com>
References: <4BAE5817.307@libero.it> <4BB1B5E5.7010203@libero.it>
	<88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com>
	<4BB1C427.8000708@libero.it>
	<ea2499da1003300239k135ae3d0k5c25a38149905db4@mail.gmail.com>
Message-ID: <4BB1C7FA.3050409@libero.it>

Dirkjan Ochtman ha scritto:
> On Tue, Mar 30, 2010 at 11:28, Manlio Perillo <manlio_perillo at libero.it> 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 the write callable?

> [...]


Regards  Manlio


From dirkjan at ochtman.nl  Tue Mar 30 11:48:16 2010
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 30 Mar 2010 11:48:16 +0200
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <4BB1C7FA.3050409@libero.it>
References: <4BAE5817.307@libero.it> <4BB1B5E5.7010203@libero.it> 
	<88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com> 
	<4BB1C427.8000708@libero.it>
	<ea2499da1003300239k135ae3d0k5c25a38149905db4@mail.gmail.com> 
	<4BB1C7FA.3050409@libero.it>
Message-ID: <ea2499da1003300248m63632a51t1c9189dbfbb416e7@mail.gmail.com>

On Tue, Mar 30, 2010 at 11:44, Manlio Perillo <manlio_perillo at libero.it> 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

From arw1961 at yahoo.com  Tue Mar 30 16:05:47 2010
From: arw1961 at yahoo.com (Aaron Watters)
Date: Tue, 30 Mar 2010 07:05:47 -0700 (PDT)
Subject: [Web-SIG] wsgi.errors and close method
In-Reply-To: <88e286471003300206p296d73bdy21370daddb1a8edf@mail.gmail.com>
Message-ID: <369837.7471.qm@web111706.mail.gq1.yahoo.com>

...
> 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 makes
> sense, because
> you can't trust people to read the documentation properly.

I don't think it's silly.  This is why static typing
is useful.  I'm involved in migrating a large amount
of java code to a new base right now and I have to say
that it's pretty nice to know that if it compiles it
will most likely work.

playing devil's advocate
 -- Aaron Watters

===
% ping elvis
elvis is alive


From manlio_perillo at libero.it  Tue Mar 30 22:29:47 2010
From: manlio_perillo at libero.it (Manlio Perillo)
Date: Tue, 30 Mar 2010 22:29:47 +0200
Subject: [Web-SIG] WSGI safe write callable using greenlet
Message-ID: <4BB25F3B.1010806@libero.it>

Hi.

In this period I'm upgrading my WSGI implementation for Nginx:
http://hg.mperillo.ath.cx/nginx/ngx_http_wsgi_module/

I'm not only updating the code to work with recent Nginx versions (after
 2 years) but, above all, I'm cleaning up the code, removing stuff not
strictly required and hard to maintain.

I have already removed support to multiple Python subinterpreters, and
now I'm going to remove the async extensions I wrote (there will only
one very simple API, for applications using greenlets); finally I would
like to remove support to the write callable.

The problem, to put it simple, is that the write callable *can not* be
implemented in an asynchronous web server like Nginx.

I have two implementations:
* the first (not the default), simply keeps a buffer.
  This is explicitly forbidden by WSGI.
* the second puts the Nginx connection socket in synchronous mode;
  it works but it is something that *should not* be done.

So, I was thinking: what about a WSGI middleware that, using greenlets,
expose to the application a write callable with the correct code flow?


Here is a very first draft:
http://pastebin.com/4k1Ep4dH

It should work with every standard WSGI implementation.

I would really like to recevive feeback about this implementation, since
I have never used greenlets before.


P.S.: LICENSE is a MIT license


Thanks   Manlio