What side effects should one expect when method decorator replaces self?

Question

I want to execute a method with a copy of the original self passed while execution.

Here is the code I'm talking about:

def protect_self(func):
    from copy import copy
    from functools import wraps
    @wraps(func)
    def decorated(self, *args, **kwargs):
        self_copy = copy(self)
        return func(self_copy, *args, **kwargs)
    return decorated

In my understanding the copy function creates a new object of the same type and copies the __dict__ of the old one to the new object (using references, so changes to actual object instances in __dict__ will still affect the original object).

Does this mean I can be sure that the decorated method cannot modify __dict__ of the original instance?

Just to make sure: I don't need a secure sandbox behaviour. My purpose is just to have a single object instanciated which I will use as a factory. The protected method should be possible to modify the passed self but it should be reseted afterwards.

Answer 1

The copy makes it so the 'self' passed to the decorated function is a shallow copy of the original. The decorated function can't modify the original 'self' directly, although it can of course modify it through other means (if it has indirect access to it.) If any of the attributes of the object are mutable, it can effectively change the original 'self' by modifying the attributes.

Additionally, any piece of (arbitrary) Python code has indirect access to pretty much any object in the program. The decorated function could gain access to the original 'self' through stack inspection, or through the gc module, for example. Your usecase seems a little convoluted; are you sure you should be using a class instance for this?

Answer 2

As the OP clarified in a comment that the purpose is to be threadsafe, then there's an obvious issue -- copy.copy itself isn't threadsafe, in addition to the issue already pointed out, that copy.copy makes a shallow copy and so (while self.__dict__ itself won't be modified) mutable objects can perfectly well get altered. Using copy.deepcopy deals with this (at a potentially hefty price in terms of performance) but in a sense even worsens the issue of thread-safety (since deep-copying can take so much longer than shallow-copying, the risk of a race condition actually occurring grows by leaps and bounds -- not that I'm in any way, shape or form recommending having race conditions that occur "only rarely", mind!-).

If you have to make originally-unsafe methods thread-safe, you'll have to bite the bullet and use locks (or a Queue and an auxiliary thread to serialize the operations) -- I guess that if you further need to silently ignore the methods' attempts to alter objects, you'll moreover have to deepcopy everything (why stop at self -- what if those methods were altering globals, for example?!-). Seem a very iffy proposition to me.