I notice you mention post/pre conditions (something that UML obviously talks about). I wonder if we want to do a bit of research on Eiffle and it's contractual description. The only thing I wonder is if some of this is actually useful programatically, if that makes sense? It's great info, but is it useful at runtime?
In Eiffel (I've never heard of Eiffle :-), pre- and post-conditions are turned into run-time checks, just like assertions. There are separate flags to turn code generation for pre- and post-conditions off. This is useful, as follows: while debugging your code, turn both on. When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging. I've heard that this works very well, and in Python 3000 (when we have optional static typing) I would love to add this to Python. If it's not feature bloat. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org> said:
When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging.
I've heard that this works very well, and in Python 3000 (when we have optional static typing) I would love to add this to Python. If it's not feature bloat.
It works very well in fully debugged applications. In the 99.99% other applications, advice is to leave the assertions on during production time so your app will fail fast when a bug pops up (profiling will point you to the two assertions that needs to be turned off for acceptable performance). Personally, but I'm talking without too much thinking here, I think support for assertions in Python should be based on generic support for metaprogramming - there's more than DBC that could benefit from that (aspect-oriented programming, etcetera). -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
Guido van Rossum wrote:
I notice you mention post/pre conditions (something that UML obviously talks about). I wonder if we want to do a bit of research on Eiffle and it's contractual description. The only thing I wonder is if some of this is actually useful programatically, if that makes sense? It's great info, but is it useful at runtime?
In Eiffel (I've never heard of Eiffle :-), pre- and post-conditions are turned into run-time checks, just like assertions. There are separate flags to turn code generation for pre- and post-conditions off. This is useful, as follows: while debugging your code, turn both on. When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging.
Note that UnitTests are there for Python now, and they can accomplish something similar. Advantage is that the tests already separate from the code so you don't have to turn them off, disadvantage is that the tests are too far from the code to encourage their use, perhaps. A good set of unit tests that are run often during development definitely feels like a good safety net. Regards, Martijn
participants (3)
-
cg＠cdegroot.com -
Guido van Rossum -
Martijn Faassen