views:

180

answers:

3
+1  Q: 

Refresh decorator

I'm trying to write a decorator that 'refreshes' after being called, but where the refreshing only occurs once after the last function exits. Here is an example:

@auto_refresh
def a():
    print "In a"

@auto_refresh
def b():
    print "In b"
    a()

If a() is called, I want the refresh function to be run after exiting a(). If b() is called, I want the refresh function to be run after exiting b(), but not after a() when called by b(). Here is an example of a class that does this:

class auto_refresh(object):

def __init__(self, f):

    print "Initializing decorator"
    self.f = f

def __call__(self, *args, **kwargs):

    print "Before function"
    if 'refresh' in kwargs:
        refresh = kwargs.pop('refresh')
    else:
        refresh = False

    self.f(*args, **kwargs)

    print "After function"

    if refresh:
        print "Refreshing"

With this decorator, if I run

b()
print '---'
b(refresh=True)
print '---'
b(refresh=False)

I get the following output:

Initializing decorator
Initializing decorator
Before function
In b
Before function
In a
After function
After function
---
Before function
In b
Before function
In a
After function
After function
Refreshing
---
Before function
In b
Before function
In a
After function
After function

So when written this way, not specifying the refresh argument means that refresh is defaulted to False. Can anyone think of a way to change this so that refresh is True when not specified? Changing the

refresh = False

to

refresh = True

in the decorator does not work:

Initializing decorator
Initializing decorator
Before function
In b
Before function
In a
After function
Refreshing
After function
Refreshing
---
Before function
In b
Before function
In a
After function
Refreshing
After function
Refreshing
---
Before function
In b
Before function
In a
After function
Refreshing
After function

because refresh then gets called multiple times in the first and second case, and once in the last case (when it should be once in the first and second case, and not in the last case).

+1  A: 

I think it might be simpler to maintain a "nested-refresh count" that is incremented before each refresh-decorated call and decremented after (in a finally block so that the count doesn't get messed up); run the refresh routine whenever the count hits zero.

In the above example, the decorators to functions a() and b() are actually two separate instances, so one decorator's counter won't be available to the other decorator. How would you suggest doing this?
astrofrog
Pass the counter object to the decorator?
+5  A: 

To count the number of "nestings", in a thread-safe way, is a good example of using thread-local storage:

import threading
mydata = threading.local()
mydata.nesting = 0

class auto_refresh(object):

  def __init__(self, f):
    self.f = f

  def __call__(self, *args, **kwargs):
    mydata.nesting += 1
    try: return self.f(*args, **kwargs)
    finally:
      mydata.nesting -= 1
      if mydata.nesting == 0:
        print 'refreshing'

If you don't care about threading, as long as your installation of Python is compiled with threading enabled (and these days just about all of them are), this will still work just fine. If you fear a peculiar Python installation without threading, change the import statement to

try:
    import threading
except ImportError:
    import dummy_threading as threading

roughly as recommended in the docs (except that the docs use a peculiar "private" name for the import's result, and there's no real reason for that, so I'm using a plain name;-).

Alex Martelli
Isn't using a counter risky if e.g. if the user is running these functions from ipython, and control-C's the execution, isn't the risk that the counter won't go back to zero?
astrofrog
Does the 'finally' take care of premature interruption?
astrofrog
@Morgoth, `finally` guarantees execution of the finalization block (unless Python crashes, for example due to some other process performing a `kill`, or otherwise terminates abruptly, e.g. with `os._exit`) whether the `try` blocks performs normally or raises or propagates an exception (including `KeyboardInterrupt`).
Alex Martelli
Ok - thanks a lot for your solution! It works perfectly :)
astrofrog
A: 

It's not clear to me exactly what you're attempting to use this design for, and because of that, whether it's a good idea or not. Consider whether or not it's the right approach.

However, I think this does what you requested. A common object (named auto_refresh in this case) is shared by all 'decorated' methods, and that object keeps a counter as to how deep the call stack is.

This is not thread-safe.

class AutoRefresh(object):
    nesting = 0

    def __call__(self, f):
        def wrapper(*args, **kwargs):
            return self.proxied_call(f, args, kwargs)
        return wrapper

    def refresh(self):
        print 'refresh'

    def proxied_call(self, func, args, kwargs):
        self.nesting += 1
        result = func(*args, **kwargs)
        self.nesting -= 1
        if self.nesting == 0:
            self.refresh()
        return result

auto_refresh = AutoRefresh()

Tested with:

@auto_refresh
def a():
    print "In a"

@auto_refresh
def b():
    print "In b"
    a()

a()
print '---'
b()

Resulting in:

In a
refresh
---
In b
In a
refresh
Matt Anderson