[Types-sig] Type Inference I

[Tim Peters]

[John Skaller]
> ...
> For example, consider:
>
> 	x = 1
> 	y = open("something")
> 	try: x + y
> 	except: print "OK"
>
> This code is CORRECT python at the moment (AFAIK).
> It is NOT 'illegal' to add a file and an integer,
> it is perfectly correct to do it, and then handle
> the resulting exception.

What I wonder is why you imagine Guido didn't intend this; just as he
intended that your "open" call above may also raise an exception (if e.g.
"something" doesn't exist, or it does but the program doesn't have read
permission, or ...).

> There is no hope for any kind of type inference
> until this is fixed. What must be said is that
> this case is an error, and that Python can
> do anything if the user does this: the result
> of executing the code MUST be undefined.

I think this is dead on arrival; almost nothing in Python was intended to be
undefined.  It might help if you gave an example that actually presented a
difficulty <wink>:  above, *if* you get beyond the "except", x is an int and
y is an open file object, and an inferencer shouldn't care what the type of
"x + y" is (it's not referenced).  Change it to "z = x + y", and an
inferencer knows that the type of z is the same as the type it had before
entering the block of code shown (because the inferencer knows that int+file
will blow up, so z won't get rebound

> The fact that a particular implementation throws an exception,
> is good behavour on the part of that particular implementation,
> but it must NOT be required -- because that would prevent
> a compiler rejecting the program.

This SIG is *adding* (optionally enforced) rules about when compile-time
detectable potential TypeErrors can cause compile-time rejection (just
"potential" because nobody has signed up to do reachability analysis; that
is,

    def f():
        return 2
        3 + open("3")

will probably get rejected in typecheck mode, despite that no runtime
TypeError is possible (the offending stmt is unreachable)).

> ...
> The outcome of this is that really, the only times python
> guarrantees to raise an exception is for environment errors,
> or for typing/indexing/lookup errors which are locally
> wrapped.

This certainly wasn't the intent!  E.g., in certain endcases, and sometimes
platform-dependent ones, Python has failed to raise OverflowError when
appropriate ((-sys.maxint-1)/-1 on (at least) Pentiums is the most recent
example that comes to mind).  Guido has always considered such behaviors to
be bugs in the implementation, and either fixes them or makes me do it
<wink>.

> ...
> ** Keyboard Interrupt: this is wrong wrong wrong!! <g>

Agreed there!

but-probably-not-a-complaint-for-the-types-sig<wink>-ly y'rs  - tim