Hi! Thank you for a quick and informative response!
> I'd go for 'manually decorating' anyway. Metaclasses can be really handy > for framework-like stuff, but for the use case you describe, I think the > explicit decorator option is much more, well, explicit - and also more > flexible - than metaclass black magic. Yes, point taken. > This may also help you distinguish 'published' API from implementation (which > is what > CherryPy do) Hmm... I'm not sure I understand how manually decorating would help me do that? With SimpleXMLRPCServer.register_instance(obj) all public methods of obj are published for XMLRPC, decorated or not. Off course, I could write a @do_not_publish decorator, but that seems backwards to me... I'm not familiar with how CherryPy works either, I'm sorry to say. > And finally, this may let you organize your code more freely - you > can mix methods needing different decorators in a same class. One can still do that, even if one would use a metaclass to set the "bare necessities" decorators. All you have to do is add the extra ones manually. I just meant to let the metaclass do the really, really important ones for me (the validator for each API class). The ones that I can't, won't, mustn't forget to add lest the Script Kiddies of the Internet come brutalizing my data. :-) > You would then have a 'server' class that just provides common > services and dispatch to specialized objects. Neat. It won't play nice with dir() or SimpleXMLRPCServer's introspection functions though (system.listMethods(), system.methodHelp()). That may be a showstopper, or do you know of any fixes? > My 2 cents... Thanks! Those were what I was hoping for, after all. Thanks for your help! /Joel -- http://mail.python.org/mailman/listinfo/python-list
