Rahul <[EMAIL PROTECTED]> wrote: > I am assuming that optional type checking is being added for easier > debugging only. So if 'expects' are turned on , python raises > warnings(which do not halt the system) but not when they are turned > off. These will enable easier debugging for new people while not > affecting masters. Also,perhaps, it will be easier to accomodate till > type checking mechanism is perfected(if it is implemented at all that > is) so that python does not stop you when it is in fact python which > might be making some mistake.(This last statement is a guess only...) > > It is similar to assert and __debug__=1 in a way. > > So the crux is : > 1.Expects is only a bridge between type checking and dynamic typing. > 2.Type checking is done only as a tool which you are free to override > if you want to. > 3.The objective of type checking here is only to make debugging easier > and not speed/optimization. > 4.The point is not that 'expects' be a additional keyword.You can go > like this also : > def (int a,int b): or whatever you like. Only that expects make it a > bit clearer IMHO. > > sincerely., > rahul
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. In a function's contract, not only could it state that its parameter must be an integer, 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. - Mike -- http://mail.python.org/mailman/listinfo/python-list
