STINNER Victor added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26643> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
