xmlrpclib and methods declared at runtime

[squid]

First off, I'm a python neophyte, but I'm fairly experienced with
Java, C and PHP.

I've been trying to use the xmlrpclib to perform remote calls against
a service, and it works nicely. However, due to my lack of
python-knowledge, I'm rather puzzled at the way the class works.

Specifically, suppose I have something like this snippet of code:

from xmlrpclib import ServerProxy

client = ServerProxy('http://some_service')

client.system.listMethods() #not declared in class
client.MyService.SomeOperation() #not declared in class
client.MyService.DoStuff() #not declared in class


Coming from mostly a java background, this is kind of freaky How is
is the ServerProxy implementation doing this? That is, creating, or
perhaps binding is a better term, these additional functions at
runtime?

Based on having read the python tutorial and remembering the list of
built-in functions, my guess would have been calling setattr in the
constructor or after doing a listMethods operation against the XML-RPC
server.. That is, assuming the XML-RPC service supports this api..
something like that.. But that does not seem to be the case here, as a
search of xmlrpclib.py does not show ANY instances of setattr being
used. I did, however, notice some cases of classes implementing a
__getattr__ method, which leads me to the question of how the
interpreter performs lookup of methods when they are called. Does it
use getattr itself? Is it possible to, say, effectively override
getattr for a specific class, thereby returning a pointer to a generic
function that could be used to handle... well.. everything?

Regardless, if someone could explain this to me, or point me in the
direction of reading material, I'd be most grateful. I tried some
googling on stuff like "python reflection" but didn't come up with
anything that looked like this, and being a python neophyte I'm not
that up to speed on my code-comprehension yet, so trying to figure it
out on my own by reading the xmlrpclib.py would take aeons Since I
don't have any trouble using the lib, it's ok, but I like
understanding how stuff works, and this seems like a useful technique.



Regards,
squid.

 

[Brett g Porter]

Based on having read the python tutorial and remembering the list of
built-in functions, my guess would have been calling setattr in the
constructor or after doing a listMethods operation against the XML-RPC
server.. That is, assuming the XML-RPC service supports this api..
something like that.. But that does not seem to be the case here, as a
search of xmlrpclib.py does not show ANY instances of setattr being
used. I did, however, notice some cases of classes implementing a
__getattr__ method, which leads me to the question of how the
interpreter performs lookup of methods when they are called. Does it
use getattr itself? Is it possible to, say, effectively override
getattr for a specific class, thereby returning a pointer to a generic
function that could be used to handle... well.. everything?

You seem to have gotten it. When Python can't find an attribute in an
object's dict, it then looks for the magic __getattr__ method. If it's
present, it passes that method the name that you're looking for. This
lets you synthesize attributes and methods at runtime.
.... def __getattr__(self, name):
.... return name.upper()
....'TEST'

With xml-rpc, a method call on your side of the connection is
implemented by building up an XML message and sending it to the server
-- rather than statically try to figure out what oprations the server
supports, xmlrpclib will happily attempt to call any method name that
you can think of, and let the server tell you if there's an error.



It's probably not a good idea to let __getattr__ handle EVERYTHING your
class needs to do, but in cases like this where you don't know in
advance what the class will need to handle, it lets your code hide the
magic in a way that lets the users of your code forget that there's
anything magic going on at all. It just looks like code.

 

[squid]

<snip>

Brett,

Thanks a bunch for the explanation!



Regards,
squid.