On 4/4/02 1:09 AM, "Ian Bicking" <[EMAIL PROTECTED]> wrote:
> On Tue, 2002-04-02 at 17:22, Tavis Rudd wrote: >> I agree. At one stage I considered writing a tool that removed >> 'if debug:' statements like the Python optimizer, but gave you a >> little more control about which debug statements should be removed. >> That way you could add lots of debug code to Webware for testing and >> then change a setting during installation to totally remove that code >> for actual deployments. > > I feel like I was reading some discussion in which a variable __debug__ > was mentioned, presumably in some context like that... maybe there was > even going to be powerful optimizations when using -O... something to > look into, perhaps. __debug__ is a built in variable. From the language reference manual: > The simple form, "assert expression", is equivalent to > > > if __debug__: > if not expression: raise AssertionError > > The extended form, "assert expression1, expression2", is equivalent to > > > if __debug__: > if not expression1: raise AssertionError, expression2 > > These equivalences assume that __debug__�and AssertionError�refer to the > built-in variables with those names. In the current implementation, the > built-in variable __debug__ is 1 under normal circumstances, 0 when > optimization is requested (command line option -O). The current code generator > emits no code for an assert statement when optimization is requested at > compile time. Note that it is unnecessary to include the source code for the > expression that failed in the error message; it will be displayed as part of > the stack trace. > > Assignments to __debug__ are illegal. The value for the built-in variable is > determined when the interpreter starts. <http://www.python.org/doc/current/ref/assert.html> So 'assert' is better than using __debug__ because the optimizations are higher (the statements are completely removed, while with "if __debug__", the 'if' statement still has to be tested but will never succeed). Since Webware + friends make such high use of the assert statement, the win could be fairly high in optimized mode. The big concern is whether people are using assertions as part of the application logic (expecting them to always be there) versus debug logic. When the assert keyword first showed up, I started using it heavily as application logic before I realized what its real intent was. I've never figured out if Eiffel's assertions (preconditions, postconditions) are meant to be always in place, or only in place during development/testing. So, I think that if there is a good need to separate using 'assert' for development/testing purposes from the need to have strong Pre/Post condition assertions in an application or kit, a class/module be introduced to handle them:: def updateSettings(self, settings): Eiffel.Require(isinstance(settings, type({})), "Settings must be a dictionary") ... Eiffel.Ensure(self.settings.didUpdate()) (A very loose example, but the meaning should be clear. This example loosely based on a Java package from a quick Google search, <http://www.t-tank.com/eiffel/doc/com/t_tank/Eiffel.html>). With such a system in place, unit tests could be run with less worry of interference from other AssertionErrors being raised, and a Webware app could be run in optimized mode will still enforcing pre/post conditions. -- Jeffrey P Shell www.cuemedia.com _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
