Memoize a function so that it isn't reset when I rerun the file in Python

decorator, functools, lru, memoization, python

Solution

Writing a script to be executed repeatedly in the same session is an odd thing to do.

I can see why you'd want to do it, but it's still odd, and I don't think it's unreasonable for the code to expose that oddness by looking a little odd, and having a comment explaining it.

However, you've made things uglier than necessary.

First, you can just do this:

@functools32.lru_cache()
def _square(x):
    print "Squaring", x
    return x*x

try:
    safe_square_2
except NameError:
    safe_square_2 = _square

There is no harm in attaching a cache to the new `_square` definition. It won't waste any time, or more than a few bytes of storage, and, most importantly, it won't affect the cache on the previous `_square` definition. That's the whole point of closures.

There is a potential problem here with recursive functions. It's already inherent in the way you're working, and the cache doesn't add to it in any way, but you might only notice it because of the cache, so I'll explain it and show how to fix it. Consider this function:

@lru_cache()
def _fact(n):
    if n < 2:
        return 1
    return _fact(n-1) * n

When you re-exec the script, even if you have a reference to the old `_fact`, it's going to end up calling the new `_fact`, because it's accessing `_fact` as a global name. It has nothing to do with the `@lru_cache`; remove that, and the old function will still end up calling the new `_fact`.

But if you're using the renaming trick above, you can just call the renamed version:

@lru_cache()
def _fact(n):
    if n < 2:
        return 1
    return fact(n-1) * n

Now the old `_fact` will call `fact`, which is still the old `_fact`. Again, this works identically with or without the cache decorator.

Beyond that initial trick, you can factor that whole pattern out into a simple decorator. I'll explain step by step below, or see this blog post.

Anyway, even with the less-ugly version, it's still a bit ugly and verbose. And if you're doing this dozens of times, my "well, it should look a bit ugly" justification will wear thin pretty fast. So, you'll want to handle this the same way you always factor out ugliness: wrap it in a function.

You can't really pass names around as objects in Python. And you don't want to use a hideous frame hack just to deal with this. So you'll have to pass the names around as strings. ike this:

globals().setdefault('fact', _fact)

The `globals` function just returns the current scope's global dictionary. Which is a `dict`, which means it has the `setdefault` method, which means this will set the global name `fact` to the value `_fact` if it didn't already have a value, but do nothing if it did. Which is exactly what you wanted. (You could also use `setattr` on the current module, but I think this way emphasizes that the script is meant to be (repeatedly) executed in someone else's scope, not used as a module.)

So, here that is wrapped up in a function:

def new_bind(name, value):
    globals().setdefault(name, value)

… which you can turn that into a decorator almost trivially:

def new_bind(name):
    def wrap(func):
        globals().setdefault(name, func)
        return func
    return wrap

Which you can use like this:

@new_bind('foo')
def _foo():
    print(1)

But wait, there's more! The `func` that `new_bind` gets is going to have a `__name__`, right? If you stick to a naming convention, like that the "private" name must be the "public" name with a `_` prefixed, we can do this:

def new_bind(func):
    assert func.__name__[0] == '_'
    globals().setdefault(func.__name__[1:], func)
    return func

And you can see where this is going:

@new_bind
@lru_cache()
def _square(x):
    print "Squaring", x
    return x*x

There is one minor problem: if you use any other decorators that don't wrap the function properly, they will break your naming convention. So… just don't do that. :)

And I think this works exactly the way you want in every edge case. In particular, if you've edited the source and want to force the new definition with a new cache, you just `del square` before rerunning the file, and it works.

And of course if you want to merge those two decorators into one, it's trivial to do so, and call it `non_resetting_lru_cache`.

However, I'd keep them separate. I think it's more obvious what they do. And if you ever want to wrap another decorator around `@lru_cache`, you're probably still going to want `@new_bind` to be the outermost decorator, right?

What if you want to put `new_bind` into a module that you can import? Then it's not going to work, because it will be referring to the globals of that module, not the one you're currently writing.

You can fix that by explicitly passing your `globals` dict, or your module object, or your module name as an argument, like `@new_bind(__name__)`, so it can find your globals instead of its. But that's ugly and repetitive.

You can also fix it with an ugly frame hack. At least in CPython, `sys._getframe()` can be used to get your caller's frame, and `frame objects` have a reference to their globals namespace, so:

def new_bind(func):
    assert func.__name__[0] == '_'
    g = sys._getframe(1).f_globals
    g.setdefault(func.__name__[1:], func)
    return func

Notice the big box in the docs that tells you this is an "implementation detail" that may only apply to CPython and is "for internal and specialized purposes only". Take this seriously. Whenever someone has a cool idea for the stdlib or builtins that could be implemented in pure Python, but only by using `_getframe`, it's generally treated almost the same as an idea that can't be implemented in pure Python at all. But if you know what you're doing, and you want to use this, and you only care about present-day versions of CPython, it will work.

Problem

Original source