[Types-sig] Optionality and performance
Greg Stein
gstein@lyra.org
Sun, 19 Dec 1999 15:14:51 -0800 (PST)
Good point. I think that I kind of described this difference in a previous
email, but you've stated it much more clearly.
I see type-safety as a second generation step, building on top of
type-checking. Can we defer these issues to a V2 system?
In general: I'd be happy with adding a "typesafe" keyword, but I think it
would behoove us to keep things small and simple. Let's just do
type-checking and defer type-safety and assignment enforcement.
Cheers,
-g
On Sun, 19 Dec 1999, Paul Prescod wrote:
> 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.
>
>
--
Greg Stein, http://www.lyra.org/