> The options I see: > > 1. Move processes to a private attribute, deprecate processors, then do it.
From an abstraction standpoint, that makes sense. Probably the same could be said about the other process related dict attributes like protocols, delay, etc., though. They all seem to be "name" indexed dicts of things related to a given process. In other words, moving processes into a private attribute suggests making all (most?) other attributes private as well. > 2. Have a parallel dictionary to processes Given that there are already lots of interrelated dicts, I'd say this would continue the current design which, as we're seeing now, is not easily extendable. I'd try to avoid this. Sidenote: A quick, mostly backwards compatible, change could probably add cwd to the existing per-process tuple in self.processes as an extra item, couldn't it? Not 100% backwards compatible, because the tuple would have one more element, but nearly 100%. > 3. Move, as Glyph suggested, to object with attributes. For backwards > compatibility, I can support __getitem__ for the historic unpackers. This feels cleaner and better. Maybe __getitem__ could be implemented and deprecated immediately, who knows? Again, creating a class here could also induce doing something similar with the "process policy/state attributes" (for the lack of a better name), where maybe the other dicts could somehow be brought together. Whether this is a better design or not is up for consideration. But one thing is a fact, just bringing them together into a common class (and, thus, down to a single attribute in ProcessMonitor) would break backwards compatibility for some of the same reasons you are now raising. *sigh!* > 4. Decide we're going with "incompatible change", and move processes to a > private attribute. I see no reason for accessing those attributes from "outside of ProcessMonitor" but if Twisted claims not to break existing code without previous deprecation warning, such an approach would break that promise (full policy details here http://twistedmatrix.com/documents/current/core/development/policy/compatibility-policy.html). My 2c. Regards, -- exvito _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
