[Types-sig] Optionality and performance
Sun, 19 Dec 1999 16:29:18 -0600
Greg Stein wrote:
> I'm saying we don't declare a need for type-safety. I'm saying that
> type-safety checking is preconditioned on two things:
> 1) type-checking is enabled when the module is compiled
> 2) type annotations are present
And I'm saying that there are times when "as many as possible" is not
enough. It is my presumption that this function will *always* pass the
def foo() -> String:
# 10,000 lines of code
print "abc"+eval( raw_input() )
return str( abc )
Its declaration is correct. Sure, it may raise TypeError but Python
isn't Java and we should make it easy to write partially type-safe code.
The return value is verifiably correct and that is all that matters.
But the same function would *never* pass the type checker if it was
decl type-safe foo
Because its declaration is *incorrect*. Even though it returns what it
should it is NOT typesafe because it can trigger one of TypeError or
AttributeError. type-safe means safe in the Java/C++ sense which is a
very different issue.
There is no reason to require foo to be moved to a separate module if it
is the only function that requires that level of safety. I can think of
no interesting reason to require all functions in a module to have the
same safety level.
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
Three things see no end: A loop with exit code done wrong
A semaphore untested, and the change that comes along