Michael Hobbs <[EMAIL PROTECTED]> wrote: > Your proposition reminds me very much of Design by Contract, which is > a prominent feature of the Eiffel programming language. Considering > that Python is an interpreted language where type checking would > naturally occur at runtime, I think Design by Contract would be more > appropriate than static typing.
I entirely agree with this opinion. > In a function's contract, not only could it state that its parameter > must be an integer, I'd like to be able to state something about the *INTERFACE* of the parameter, to the rigorous exclusion of its *TYPE* (which is an "implementation detail"). I doubt it's really feasible, but, in Haskell terms, I'd love for such assertions to be always and necessarily about _typeclasses_ rather than _types_... > but also that it must be > 50 and be divisible by > 7. If a value is passed to the function that violates the contract, > it raises an exception. > > In Eiffel, contract checking can be turned on or off based on a > compiler flag or a runtime switch. I've always liked the (theoretical) idea that assertions (including of course contracts) could be used as axioms used to optimize generated code, rather than (necessarily) as a runtime burden. E.g. (and I don't know of any implementation of this concept, mind you), inferring (e.g. from such assertions) that x>=0, and that y<0, the compiler could simply cut away a branch of dead code guarded by "if x<y:" (maybe with a warning, in this case;-)... Alex -- http://mail.python.org/mailman/listinfo/python-list
