[TransWarp] input-driven application - assembling filters
Phillip J. Eby
pje at telecommunity.com
Fri May 16 14:21:34 EDT 2003
At 08:49 PM 5/16/03 +0300, alexander smishlajev wrote:
> def run(self):
> self.uponAssembly()
> self.mainLoop.run()
>
> def uponAssembly(self):
> super(Echo2, self).uponAssembly()
> _pipe = self.pipe
Please don't do this. It isn't safe to override 'uponAssembly()' and call
it with 'super()'. The standard way to capture an assembly event is:
def setupPipe(self,d,a):
#....
setupPipe = binding.whenAssembled(setupPipe)
'uponAssembly()' has rather complex logic to safely handle unintended
recursion, and to prevent double execution. Your subclass has no means to
handle this, so the body of your method might get executed twice under
certain circumstances.
You'll notice that AdaptiveTask and other PEAK classes define
'whenAssembled()' bindings, rather than overriding 'uponAssembly()',
because even I don't know how to safely override it. ;)
Also, note that if you use the most-updated CVS version of PEAK, your run()
method will not need to call 'uponAssembly()', as it will be called
automatically for you, well before your run() method gets called.
> self.stderr.write("=== Pipe: %r\n" % (_pipe,))
> self.filter1.stdin = self.stdin
> self.filter2.stdout = _pipe[1]
> self.filter2.stdin = _pipe[0]
> self.filter2.stdout = self.stdout
>
>==== end cut Echo2.py ====
>
>
>this module works ok, but i think that there may be a better way to
>connect inner filters together. right?
It depends on what you mean by "better". :) What did you have in mind?
>ps. by the way, Phillip, if you think that such NonBlockingPipe could be
>useful addition to the PEAK, i may donate the code to you.
It sounds nice, but as I'm not particularly expert in these pipe-and-filter
matters, and this isn't a core use case for PEAK, and finally, because
every piece of code we add ultimately needs documentation and unit tests, I
will have to decline the offer, at least for now.
More information about the PEAK
mailing list