Ian Bicking: the old part of his blog

Re: Sad conflicting packages

I agree with the general lament: that an unambiguous namespace means having to deal with packages that have the same name.

You can, of course, get around that in any specific code with import foo as bar.

In this specific case, though, should the JSON code just be reimplemented using PyDispatcher? I must admit to sharing your preference for the simple, hugely flexible PyDispatcher.

Comment on Sad conflicting packages
by Ben Finney

Comments:

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?

# anonymous

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

PyDispatcher doesn't really apply to the JSON code, so that's not an option. The name conflict doesn't help, because you simply can't have two distributions loaded with the same top-level name (except maybe with the technique PJE mentioned, though that requires repackaging the libraries, at which point I could just rename the package).

# Ian Bicking

Well, I was suggesting that if enough people asked for it, then the authors of the respective packages (i.e., me and Patrick O'Brien) would probably be willing to include that code for compatibility's sake.

# Phillip J. Eby

Patrick doesn't do much with PyDispatcher these days AFAIK, but I'd certainly be willing to incorporate changes that would let the two packages coexist. Heck, if I recall correctly from our earlier discussion the two packages can actually be dumped into the same directory and both continue to function as expected.

# Mike Fletcher

Hmm, should have finished reading the whole comment thread. Apparently Patrick is all over it :) .

# Mike Fletcher

I'm more than happy to defer to you, Mike, since you've been shepherding the code for some time now. I appreciate all the work you've done to make the code available, fix bugs, add enhancements, etc.