Doug: It sounds like your criticism is that the LambdaDict can’t cache things the builtin Dict it’s based can’t cache. I’m OK with that limitation. I agree that injection is a great way to shoot yourself in the foot, that’s why I talked about it as garnish rather than a side dish. I’ve avoided the pitfalls, though I admit that’s at least partially luck.

Philip: Defaultdict doesn’t work here, it can’t pass arguments or do the other things that Justin noticed I elided from my example.

Dave: Great, got a link? I spent a while searching for code before writing my dict, but I didn’t think to search for “memoize” (obvious now that you’ve said it).

(Thanks for the great comments, folks. I’ve add <code lang=”python”>…<code> where needed.)

The pythonic solution is to write a memoizing decorator – or use one of the many already in the ASPN Python Cookbook.
Then you can do

 
@memoize
def expensive_calculation(...):
    ....

@david: I like that solution.

 
results = {}

for item in really_big_list:
    result = results.setdefault(key, expensive_calculation(key))
    # … do something useful with item and result

Then you don’t need a custom class.

Open classes are an entirely different issue. It can be really handy when tinkering around with things. Though, like Doug points out, when it comes to a large application with many libraries, all maintained by multiple developers, it becomes an easy way to shoot yourself in the foot

For instance, your implementation has some issues. It will not work if your attribute is a dictionary as dictionaries are not hashable and can’t be used as keys. If it is a complex object, the hash will be on the instance id (pointer) verses the data it contains unless you override __hash__. I have seen a number of examples of caching using decorators and descriptors (I often use a descriptor decorator to do dynamic caching of attributes).

I have used ruby extensively and run into similar issues with using the builtin caching behavior. In the end, most of the time I had to write my own (as I rarely deal with simple things).

In the end, ruby has some native helpers for the most common use cases, but it is easy enough to write generic python decorators or descriptors to do the same thing in python.

As for monkey patching… Well one of the things I hate about Ruby is injection. It has cost the company I work for hundreds of hours of grief. The real problem are the people using the language all injecting their crap without regard to what other people are doing, but that is what researchers do. And I hate it in python even more (as ruby gives you some protection from bad things where python gives you none).

yes its cool, yes it allows you to do some very powerful things… but it is a bad thing to do in a large codebase with multiple people who don’t talk to each other about every change they make (which is 90% of ‘professional’ software development.) As one researcher said after a week of debugging, ‘That is some beautiful rope we hung ourselves with.’

http://plone.tv/media/430268733

Note that in the Zope world where the term monkey patch originated from, the dynamic class modifications of Archetypes is *not* called monkey patching. Monkey patching only applies where your reason for re-opening a class is in order to patch it to fix bugs or mis-features similar to traditional software patches:

http://www.catb.org/esr/jargon/html/P/patch.html

?