A __getattr__ for class methods?

[Xavier Morel]

Dylan Moreland wrote:
> I'm trying to implement a bunch of class methods in an ORM object in
> order to provide functionality similar to Rails' ActiveRecord. This
> means that if I have an SQL table mapped to the class "Person" with
> columns name, city, and email, I can have class methods such as:
> 
>     Person.find_by_name
>     Person.find_by_city_and_name
>     Person.find_by_name_and_city_and_email
> 
> I have a metaclass generating basic properties such as .name and .city,
> but I don't want to generate a class method for every permutation of
> the attributes. I'd like to have something much like __getattr__ for
> instance attributes, so that if a method like
> Person.find_by_city_and_email cannot be found, I can construct a call
> to the basic find method that hides the SQL. Is there any way of doing
> this, or am I trying to mirror a functionality that Python simply does
> not have?
> 
I'm not sure that the way you tackled this is the good approach: while 
it's quite flexible as far as the search criteria go, it'll require less 
than obvious code to match keywords (field names) and values, will lead 
to somewhat verbose syntax (especially with many criteria), and the 
syntax itself is unforgiving (every new search field requires at least 5 
additional characters on top of the field name itself), brittle (you'll 
have to do an extensive validation of your method name and fields unless 
you want everything to break, and Python doesn't support your syntax) 
and not really pythonic.

Since you seem to know ActiveRecord, you're probably familiar with the 
way AR does this task: with a hash of column_name, value pairs. The 
syntax is quite straightforward especially due to the fact that any "key 
=> value" comma-separated pairs sequence generates a hash, without 
requiring explicit hash boundaries ( { and } ). The syntax is extremely 
straightforward since it relies on the language's syntax itself, and the 
correctness of the grammar is checked by the compiler/interpreter itself 
since no custom syntax is built. This construct is therefore quite 
solid, on top of being obvious to a Rubyist.

Now, you're in luck, because Python has even better than that: **kwargs, 
the optional keyword arguments.

As you probably know, Python has a good support for keyword args, 
allowing you to fill your arguments out of order (and leave the 3th 
argument at it's default value while specifying the value of the 5th 
argument). But **kwargs goes beyond the regular explicit keyword 
arguments: when specified, **kwargs is a dict populated with the 
implicit keyword arguments (keyword:value pairs), the ones you haven't 
specified in the argument tuple of your method.

This means that if I define a function as

def foo(bar=0, **kwargs):
     print kwargs

Then calling foo() will print an empty dict
As will calling foo(3) or foo(bar=3), because the explicit "bar" keyword 
argument is used.

Now if I call foo(something=5, somethingelse="woohoo"), kwargs will 
evaluate to

{"somethingelse":"woohoo","something":5}

This means that all you have to do is replace your method definition with

 >>> def find_by(cls, **kwargs): pass

and in the method itself iterate over the key:value pairs of kwargs to 
automagically get both the field names and the values upon which your 
search shall be performed.

Calling the method would then look something like:

 >>> Person.find_by( name="thenameyoulookfor", city="somecity")
the syntax is fairly obvious and pythonic, has a low verbosity, and 
Python itself will do the parsing and the grammatical validation of your 
method calls for you.