Gregory Salvan added the comment: In case it helps, I've experienced a similar refactoring.
we used a pattern of stages and services: - stages represent a state of the application (like Pre-Initialization, Initializing, Initialized...), they are composed of services - services represent a key responsability over the system (set program name, set python home...) The launching sequence was determined by a game of dependencies. ex: "Initialized" claims it requires "Initializing" which claims it requires Pre-Initialisation... So when you ask to load stage Initialized the launcher can construct then run the sequence: Pre-Initialisation -> Initializing -> Initialized. We used same mechanisms for Services. This way you can insert/append new stages or services just by creating them and declaring they should be run after X and/or before Y. Key benefits: - easy to maintain and extend, flexible - thread safe, launcher/runner can take the decision to parallelize. To serve this purpose each service can take a context object and return the context object that will be passed to the next service, between each stages contexts are merged if parallelized... - easy to debug: you've got error messages like: At Stage X, service Y fails with error message Z. - optimization friendly: while debugging you can measure the time taken by each service and compare it with and older version of the system for example. - few changes to original code, it's just copy/pasting chunk of code. Drawbacks: - it's hard for developpers to have a picture of what happens, this require to make a launcher/debugger which can dump the launching sequence. ---------- nosy: +Gregory.Salvan _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22257> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
