[Reposting my original reply at the very bottom of this, since I sent it from
the wrong email address last time and it never hit the mailing list -- for
those following along there.]
And Pete, that PEP isn't exactly great and we all definitely translated it
differently before. :) Some parts are confusingly worded, it's really long, but
at one point in the doc it actually is explicit -- search for Note: the
application. I was pretty surprised when I found that gem and I thought I'd
read the whole spec at one point, but had obviously missed that. I'd probably
fallen asleep, twice.
-- gholt
On May 21, 2012, at 8:22 PM, Pete Zaitcev wrote:
On Mon, 21 May 2012 16:06:42 -0500
Gregory Holt gh...@rackspace.com wrote:
There are examples of middleware returning generators out there, such as
in PEP 333 WSGI, specifically the class example at
http://www.python.org/dev/peps/pep-0333/#the-application-framework-side.
Obviously I didn't read the PEP closely enough, so I assumed the opposite.
Sorry. Here's my message about it:
https://lists.launchpad.net/openstack/msg11261.html
That is something that swift.common.wsgi.WSGIContext's _app_call works
around, ensuring the generator is activated before returning.
I see, I missed that.
Thanks,
-- Pete
On May 21, 2012, at 4:06 PM, Gregory Holt wrote:
Pete, I'm not sure I understand the problem. What do you mean by middleware
should complete by the time __call__ returns? There are examples of
middleware returning generators out there, such as in PEP 333 WSGI,
specifically the class example
athttp://www.python.org/dev/peps/pep-0333/#the-application-framework-side.
When a function is called that returns a generator, the generator is returned
immediately and no actual code in the function is called until the generator
first begins to iterate. This example code might show what I mean:
def start_response():
print 'three'
def genfunc(sr):
sr()
yield 'four'
print 'one'
gen = genfunc(start_response)
print 'two'
for item in gen:
print item
Much code, including older Swift-related middleware, often assumes
start_response is called right after calling the genfunc call and before
print 'two', but this is not the case. It is delayed until the generator is
first iterated over. That is something that swift.common.wsgi.WSGIContext's
_app_call works around, ensuring the generator is activated before
returning.
Is there some other issue you're having? The newest swift3 now subclasses
WSGIContext.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
