[Types-sig] Optionality and performance

[Paul Prescod]

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
type checker:

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
declared type-safe:

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
http://www.geezjan.org/humor/computers/threes.html