predicting function calls?

Ernst Noch enoch at
Sat Dec 31 14:40:37 CET 2005

Roy Smith wrote:
> I think I know the answer to this, but I'll ask it just in case
> there's something I hadn't considered...
> I'm working on a python interface to a OODB.  Communication with the
> DB is over a TCP connection, using a model vaguely based on CORBA.
> I'll be creating object handles in Python which are proxies for the
> real objects in the database by doing something like:
> handle = connection.getObjectHandle (className, instanceName)
> Objects can have attributes (data) and operations associated with
> them.  It would be very convenient to use the "." syntax to access
> both of these, i.e. be able to say:
> print handle.someAttribute
> print handle.someOperation (arg1, arg2)
> I'm using __getattr__() to process both of these constructs, and
> herein lies the rub; I need to do different things depending on
> whether the name is an attribute or an operation.  I can ask the DB
> for a list of the names of all the operations supported by a given
> object, but that's a fairly expensive thing to do, so I'd rather avoid
> it if possible.  It would be really nice if I had some way to find
> out, from inside __getattr__(), if the value I'm about to return will
> get called as a function (i.e., the name is followed by an open
> paren).  I can't see any way to do that, but maybe I'm missing
> something?

For various reasons also mentioned by other posters it's also not clear 
to me how relying on user input should work. Esp. for the

print x(args)


Couldn't you just, for every access to a member of your object, first 
try to treat is as an access to an operation? If this fails (you 
mentioned the db will throw an error if this is an attribute instead of 
an operation), fall back to ask the db for an attribute of that name.

Or maybe just ask the db to look up this attribute in the list of 
operations, depending which is faster.

Btw. if the system is very dynamic, you might have to think about also 
implementing the attributes as proxies.

More information about the Python-list mailing list