Ian Bicking: the old part of his blog

Sad conflicting packages comment 000

I may be a little naive about event dispatching mechanisms, but when it comes to simplicity, how simple can they get, and exactly what flexibility is required?

I've used FibraNet (back when it was just called 'EventNet'), the event/signal mechanism in PGU, and PyDispatcher. From my experience, EventNet was the most simple. One line to post an event:

eventnet.driver.post('my_event', arg1=something, arg2=something_else)

and one line to register a callable to receive an event:

@eventnet.driver.subscribe('my_event')

def my_event_handler(event): print event.name, event.arg1, event.arg2

EventNet does force you to keep track of references, and explicitly unsubscribe event handlers, as it does not use weak references. This can result in some extra code.

I've found writing code like this can be either very elegant, or very confusing. This situation gets amplified (for better or worse) once you start using the eventnet.net module, which works well for simple IPC, though I do not know how safe it is.

I am curious, how exactly are you planning to use an event dispatcher in SQLObject, and what problems will it help solve?

Comment on Re: Sad conflicting packages

Comments:

How is this simpler:

eventnet.driver.post('my_event', arg1=something, arg2=something_else)

Than this:

dispatcher.send('my_event', arg1=something, arg2=something_else)

Or listening with:

dispatcher.connect(my_event_handler, 'my_event')

It's not a decorator, but that would be very easy to implement. PyDispatcher also has has the concept of "sender", which I find useful, as I'm actually expecting to listen to events on a per-class basis (and SQLObject classes are the senders).

The events I'm proposing are listed in sqlobject.events in the repository -- it could quickly become a core part of how basic concepts like joins and columns are implemented. E.g., a column with a cascade=True setting would listen for a delete event.

# Ian Bicking