> Consider your example with the 'sys.path' resource. With current code I need to understand only 3 simple lines of the code in two close methods. With the patch I need to research 4 classes with 16 complicated methods! This is awful!

I replaced get_sys_path()/restore_sys_path() (2 methods) with ModuleAttr.get()+ModuleAttrList.encode_value() / ModuleAttr.restore()+ModuleAttrList.restore_attr() (4 methods).

I want to factorize the code to limit duplicated code.

My use case is that I want to see what changed when I get the "test xxx changed yyy" error. For sys.path, ModuleAttrList.decode_value() helps to get a nicer output since you only display 1 list instead of the (id, list, list_copy) tuple.

How do you suggest to enhance the existing code to get such nicer output?


> Now about using __subclasses__(). Is it guarantied that the order of classes in __subclasses__() is the same as the order of declaration and always will be?

No, it looks random.


> The order of restoring resources matters.

I'm not sure that it's a good thing to have dependencies between "resources". I see that Files depends on Cwd, but maybe the Files check can be integrated into Cwd?

Ok so the order matters, in this case, I can use a metaclass to use the order of class definition. It will make get_resources() simpler, it will be build directly in the metaclass.

> For now if there is needed to change the order of restoring resources (I'm sure there will be need to do this in future) you need to change only one or two lines. With your patch you need to reorder classes declarations.

Yes. Is it really an issue? I only see two resources that have a dependency (Files and Cwd). It's not like this file is modified regulary.


> Nicer diff for dictionaries can be an enhancement, but it can be implemented without such large rewriting.

How do you want to implement that? Currently, a resource has a "get" method which returns a blackbox. It's not easy to display it. There is not standard format.