[PEAK] A taxonomy of event sources: designing the events API

[Bob Ippolito]

On Jan 7, 2004, at 10:13 AM, Phillip J. Eby wrote:

> At 10:02 AM 1/7/04 -0500, Bob Ippolito wrote:
>
>> On Jan 7, 2004, at 9:42 AM, Phillip J. Eby wrote:
>>
>>> At 12:12 PM 1/7/04 +0100, Ulrich Eck wrote:
>>>> I'm really looking forward to rewrite my workflowstuff to use
>>>> peak.events .. it will fit perfectly i think :))
>>>
>>> Keep in mind that generators can't be pickled, so you really can't 
>>> use events.Thread objects to represent workflows that last longer 
>>> than a single program run.
>>
>> Stackless Python pickles generators! :)
>
> ...and IIRC, it does so by also pickling the code object involved, 
> which doesn't provide any opportunity for workflow process evolution.  
> That is, if you change the code, existing instances are unaffected.  
> For certain circumstances that's useful, for others it's not what you 
> want.  At least, it's not what I want as the primary mechanism for 
> saving state.

Well uh.. of course it has to pickle the code object.  It wouldn't work 
otherwise, changing the code object would make the live generator 
invalid in a whole bunch of different ways.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://www.eby-sarna.com/pipermail/peak/attachments/20040107/2c397aba/smime.bin