[Types-sig] Implementability

Tim Peters tim_one@email.msn.com
Fri, 17 Dec 1999 04:28:12 -0500

>     declared_int = unknown
> is an error, but

[Martijn Faassen]
> Or, if you're interfacing with untyped python, this could raise a
> run-time exception if unknown doesn't turn out to be an integer. Or do
> you disagree with this?

Yes and no <wink>.  I think "type-checked Python" needs at least three
different compile modes, because nobody is claiming we *can* check the
entire language in a bulletproof way -- and when we can't, different people
will want different behaviors at different times for legitimate reasons.

1. Anything that can't be proven safe at compile-time is a compile-time
   error (that's where I disagree with you above).

2. Anything that can't be proven safe at compile-time is checked
   at runtime (that's where I agree with you above).

3. Anything that can't be proven safe at compile-time emits a
   compile-time warning, and there's no guarantees one way or the
   other about what happens at runtime (where I don't even agree
   with myself).

If someone doesn't want any of those behaviors, fine, don't enable

>>     unknown1 = unknown2
>> is not.  Whether
>>     unknown = declared_int
>> should be an error is a policy issue.  Many will claim it should
>> be an error, but the correct answer <wink> is that it should not.

> This would seem to be the natural way to do it; I'm not sure why many
> would claim it should be an error. Could you explain?

This is what I call a "self-denying prophecy".  That is, by implicitly
ridiculing the position before anyone took it, I graciously saved everyone
from suggesting it <wink>.

> I agree.

I'm going to save that sentence and paste it into other replies as needed.

thanks!-ly y'rs  - tim