[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
