This sentence is backwards. There are not problems if the *source* has a shorter or equal lifetime as the *listener*, because it is the source which is preventing the listener from being collected.

Which one are not working for you? If you let me know I can fix them

Colin E.

I meant it’s easy making strong ref from weak ref but not the other way around.

This brings me to another point.

This unpredictability is inherent to everything that uses weakref – such as Threading.Timer. Once ‘dead’ (as per your definition), the timer event may still fire a few times before it gets GC’ed, thus introducing unpredictability. That simply means you need to care about its lifetime and dispose it when you want it to stop. Same principle applies to weak events, you’d still care about its lifetime and remove the event handlers at the correct point. For consistency, I’d prefer all events be changed to weak events by default (should have been this way from the get-go). It’s easy to make a strong ref to an object from a weaf-ref, whereas an implicit strong ref makes it hard to break (in fact, it’ll be impossible if the event is in a third-party library where you wouldn’t want to change the source / haven’t got the source). The overhead to assign and call a weak event if supported natively is negligible. And with events being weak by default, developers are forced to think about the object, as opposed to the method they want triggered, when they hook it to the event.