On Tue, Jun 14, 2011 at 07:37:50PM -0400, Glyph Lefkowitz wrote: > This is the most important point to take away, and I agree with it. As much > as > possible, code should interact with endpoints as parameters. If you need to > pass something around, pass the endpoint or the service itself, not the string > or the parameters used to construct it.
Granted. > This then begs the question: where does "debug_mode()"'s result come from? Actually, there is no `debug_mode()` function, but we rewrite the configuration file before deploying it. It contains some blocks like # DEV_START GPS_PORT = "tcp:1049" ... # DEV_END and # PROD_START # GPS_PORT = "SERIAL:/dev/ttyS2:baudrate=4800" # ... # PROD_END The deployment script removes all lines between "# DEV_START" and "# DEV_END" and removes the comments between "# PROD_START" and "# PROD_END". This allows us to guarantee that development features (e.g. a manhole, a different kind of database, TCP-based stubs for serial devices like the GPS-receiver) do not "leak" into the production environment. > Presumably someone had to indicate a boolean to this code somehow. It would > be simpler for whoever was supplying the value for debug_mode to just supply a > value for the endpoint string description instead. And if it's OK to > hard-code > the debug_mode boolean, why not just hard-code the string? That's how it's implemented. Best regards, -- Albert Brandl Weiermayer Solutions GmbH | Abteistraße 12, A-4813 Altmünster phone: +43 (0) 720 70 30 14 | fax: +43 (0) 7612 20 3 56 web: http://www.weiermayer.com _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
