Weighing in on Eric's last post with regards to Pyre's current behavior and plans:
> In short, should these two cases be treated in a consistent manner?
The current pyre behavior does not refine on same-line type declaration but does when assignment happens later. However, afaik this is a bug and we support consistency as per Eric's post here. Our plan is to change this so Pyre also refines to a narrower type on same-line assignments, while keeping the broader type around to prevent assignments incompatible with the explicit annotation further on.
For more context, all of Pyre's planned follow-ups/fixes from this discussion include:
1. Stop refining variables explicitly typed as `Any` to allow for an escape hatch.
2. Be consistent about refining `x: Union[int, str] = 42` and `x: Union[int, str] \n x = 42`
3. Stop allowing explicit re-annotations of variables with the same name. Pyre is also treating typed parameters as explicitly annotated locals, so allowing re-annotation was originally supported for naming flexibility. However, this seems like a reasonable sacrifice to support Eric's Point #2.
Overall Eric's set of points aligns with Pyre's intended behavior.
The one example that may be worth clarifying:
```
a: Union[int, str] = 1 # Type is a is narrowed to int
b = [a] # Currently Pyre is using the broader type of 'a', and types 'b' as List[Union[int, str]] here.
```
The narrowed type of `int` is still useful if passing or returning `a` where `int` is required.
Thanks Shannon, I am convinced (or at least, as convinced as I was in 2016 :-). Let's just stick with what PEP 526 already requires.
I haven't run Eric's tests through mypy, but I do note that several functions there don't have any annotations -- PEP 484 says those won't be checked at all (and mypy honors this, with default options). When I have more time I'll see how mypy does on that test, at least when you separate the assignment from the declaration.