Infer variable types from simple literals in semanal.py

[gvanrossum]

This implements another partial approach to #1530. The cases in our internal repo where my previous PR (#1736) caused regressions are all fixed by this.

However I'm not fully convinced that this is the right way to go about it. Some of the tests I had to fix make me wonder. Example:

def foo(s: AnyStr) -> AnyStr:
    if isinstance(s, str):
        x = '/'
    else:
        x = b'/'
    return x

If I understand what I had to fix in posixpath.py correctly, this used to pass silently while now I have to add # type: AnyStr to the first assignment to x.

[gvanrossum]

@JukkaL: I'm pretty sure I broke something -- it can't be a coincidence that the foo() I gave above used to type-check but now requires an annotation. But my little brain can't explain it. :-(

[gvanrossum]

I was going to say "and why didn't this break any tests?" -- but then I realized that the changes I had to make to unbreak check-typevar-values.test probably provide a clue.

[gvanrossum]

I guess I must understand what 5797c39 does -- that's where the two tests I broke in that file were added.

[gvanrossum]

I think I can fix that by doing this only when it occurs outside functions. (In the future we could tighten that to "outside generic functions".)

[gvanrossum]

(FYI I rolled back the changes to posixpath.py using git manipulations.)

[gvanrossum]

OK, I feel better about this again.

[JukkaL]

Hmm, it might be useful to run the type inference at least inside __init__?

[gvanrossum]

Maybe, but what if __init__ is generic? Is there a way to identify a generic function in the function_stack?

[rwbarton]

This situation could arise if either __init__ itself is a generic function (its CallableType has nonempty variables), or the class that it is the __init__ of is a generic class.

(In principle it could happen for any function, but then there is code which is never reachable (according to mypy) and that's probably a bug anyways.)

[gvanrossum]

In any case I still need to add test cases for this feature.

[JukkaL]

Another potential test case is one where two files that form a cycle symmetrically refer to a attribute defined in the other file. This would remain a valid test case no matter in which order we'll end up type checking the modules.

[JukkaL]

Looks good, other than the ideas for additional test cases. Maybe implement simple type inference within methods in a separate PR, as this PR already implements a self-contained and useful new feature. For top-level functions and non-instance methods (maybe even non-__init__ methods) this likely wouldn't be useful.

[gvanrossum]

OK, I've got all the tests requested. Feel free to merge.