Move dictionary from instance to class level

Frank Millman frank at
Thu Aug 27 09:10:02 CEST 2009

Dave Angel wrote: 

> Any time I see multiple lists like that which have to stay in 
> synch, I think code-smell.

I don't think it is that bad, but I agree there is always room for

> Why not let the EVT's be passed as strings, and avoid the whole mapping 
> to integers and mapping back detail?  And name the methods involved in a 
> way that you can directly translate the string to the method name?

There is some merit in this. At present I am writing the server and the
client, and copy/paste the list of constants, so they are guaranteed to stay
in sync. (Maybe I should import it instead - even more fool-proof [the fool
being me, of course]).

However, it may happen that I want to open it up to 3rd-party clients in the
future, in which case I would have to publish some sort of API. It would
make more sense to identify the messages by a meaningful name rather than an

And yes, I could then use 'getattr' to retrieve the corresponding method on
the server side.

> Barring that, make a single "structure" which lists the event 
> names and 
> method names in matched pairs, and derive whatever lists and 
> dictionaries you actually need from that one structure.  And that 
> structure should be shared between client and server code, 
> perhaps as a 
> text file that they both parse.  Or as a stream that's passed 
> from one 
> to the other during startup.  That way, consistency between 
> them can be 
> regulated (with version string in the file, for example)

I'm not sure how that would work. On the client side, I need to respond to a
'button-clicked' event from the gui system by sending an EVT_BUTTON_CLICKED
message to the server. In other words it is hard-coded into the client
program. I don't know how that would work if I read in a list of
message-types at startup.

> DaveA

Thanks for the input - it is always good to have some fresh ideas.


More information about the Python-list mailing list