[mod_python] Output Filters Redeaux

Deron Meranda wrote ..
> On 4/17/06, Nick <nick at dd.revealed.net> wrote:
> > The iterator would stop when None was read, so that's implicit.  Again,
> this
> > idea assumes a producer/consumer model rather than the repeated calling
> > model that is supported now.  And that, of course, implies some kind
> of
> > thread or fork and communication through a pipe or some other form of
> IPC,
> > unless there's some aspect of the apache API that I'm not aware of (which
> is
> > highly possible :)
> 
> Not sure why you're thinking about threads and IPC?
> 
> Anyway creating a generator-wrapper is the quickest way.  But you
> could modify the filter class so it acts like an iterator pretty easy.
> Just add a new method something like (this is untested):
> 
>    class filter:
>       ....
>       def __iter__(self):
>           class filteriter:
>               def __init__(self,f):
>                   self.f = f
>               def next(self):
>                   s = self.f.read()
>                   if s is None:
>                       raise StopIteration
>                   return s
>           return filteriter(self)

Overall I can't see how it could be made to work, at least I can't see how
it could be made to work easily. The basic problem is that on each call into
a filter, it is a different filter object associated with different buckets in the
bucket brigade. So although within the context of a single filter call, you
might be able make the filter object iterable, you probably can't have one
bit of code which somehow transparently bridges the multiple calls to the
filter even if using a generator somehow, which is what I think the suggestion
was about. I don't truly grok all that can be done with generators and so
there may indeed be a way, but it would probably need to use multiple
levels of indirection to get around fact the filter object changes.

Graham