[Types-sig] RFC 0.1

[Tim Peters]

[GregS]
> ...
> 2) You *still* need inferencing. "a = foo() + bar()" implies that some
>    inferencing occurs.

The type of the RHS expression is the union of the types returned by
foo.__add__ and bar.__radd__.  I wouldn't call that inferencing, any more
than I'd say it required inferencing to determine the return type of

    math.sin(3.0)

Now you *can* call that inferencing, but doing so wouldn't be helpful
<wink>.

> ...
> The compiler can issue a warning and insert a type assertion for
> a runtime check. IMO, it should not forbid you from doing anything
> simply because it can't figure out some type. Python syntax's "type
> agnosticism" is one of its major strengths.

It sure is!  OTOH, many people write code that doesn't exploit that, and
would rather not see runtime surprises when it's *possible* to catch them at
compile-time.  And some of those would rather not be allowed to write any
code that *could* yield a runtime surprise.

Different strokes, and I say don't worry about it!  What's important is that
the type system be defined sufficiently well that the compiler can either
*know* that it knows the type of a given expression at compile-time, or know
that it *doesn't* know it.  What it does in the latter case can be
determined by a compile option.

There's really no other realistic choice, since Python's dynamicism is too
useful to allow defining a type system that's guaranteed always resolvable
at compile time.  Some people are going to want to die when it's not, others
are going to want to press on.

and-both-positions-are-ridiculous<wink>-ly y'rs  - tim