Any chance you can resolve the conflicts?

Now allows non-Optional class variables to be initialized to None, though it doesn't check that they are set to something else in init (or a method init calls).

I've figured out one of the mypy-on-mypy errors this introduces, though it's not entirely clear to me what the best solution is. Basically, the problem boils down to mypy inferring member variable types from isinstance calls but not from assignments. To be concrete:

This results in an error:

from typing import Union
class C:
    x = ""  # type: Union[int, str]
    def f(self) -> None:
        self.x = 1
        self.x + 1  # E: Unsupported operand types for + ("Union[int, str]" and "int")

But this works:

def f(x: Union[int, str]) -> None:
    x = 1
    x + 1

And so does this:

from typing import Union
class C:
    x = ""  # type: Union[int, str]
    def f(self) -> None:
        if isinstance(self.x, int):
            self.x + 1

This problem was exposed because we have code that looks like this:

class C:
    x = ""
    def f(self) -> None:
        if self.x is not None:
            return
        self.x = "foo"
        self.x.capitalize()  # E: None has no attribute "capitalize"

With this PR, mypy now understands that returning when self.x is not None implies that self.x = None for the rest of the function (because it understands foo is not None as an isinstance-style check). Mypy continues to not understand that self.x = "foo" means x becomes a str.

It's not generally sound to assume that instance variables don't change their type within a function after assignment (within the constraints of their declared type), because method calls might mutate them. So it's not obvious what the best fix here is.

On further investigation, not inferring local types from member assignment appears to not be intended behavior, but rather the result of a bug. Here's what I've traced so far:

1. In check_assignment, the binder is correctly called with the locally inferred type on this line: https://github.com/python/mypy/blob/master/mypy/checker.py#L1202
2. The binder attempts to get the declared type here: https://github.com/python/mypy/blob/master/mypy/checker.py#L232
3. The MemberExpr has no associated node property, so the check here fails: https://github.com/python/mypy/blob/master/mypy/checker.py#L218
4. MemberExprs have no associated node property because none is set in the semantic analysis phase here: https://github.com/python/mypy/blob/master/mypy/semanal.py#L1877

I assume we intend to support non-strict optional checking for the foreseeable future; if not then perhaps the following comments aren't relevant.

Seeing many occurrences of

        if experiments.STRICT_OPTIONAL:
            return UninhabitedType()
        else:
            return NoneTyp()

made me think about the following reorganization. Instead of NoneTyp and UninhabitedType, have BottomType and NoneTyp, where

• BottomType is always (regardless of whether strict optional checking is enabled) the bottom of the type hierarchy, so it is a subtype of any other type and taking a Union with BottomType does nothing. It behaves the same as the old NoneTyp.
• NoneTyp is the type of None when strict optional checking is enabled. When it's disabled, None has type BottomType (since then None belongs to every type) and NoneTyp is not used for anything.

Ideally the only difference between the two modes would be whether None is given type NoneTyp or type BottomType. This way we'll have a single type hierarchy to think about, and my hope is to remove the dependencies of modules join, meet, solve, and subtypes on the setting of strict optional checking.

I haven't yet read the whole diff carefully, so I'm not sure how this will work out in practice.

Something we might want to think about before too long is whether it makes sense to check some parts of a program (e.g., some of its dependencies) with strict optional checking and others without, and how we might plan to support that.

Honestly I would be happier if this was for a brief period only. But not sure how realistic that I.

I agree with Guido: I think it would be best to target having this only for a brief period.

@rwbarton: I've thought about your suggestion, and I think it can work, but I actually find the current way of thinking about things to be easier. Making sure BottomType behaves appropriately in both interpretations could get a bit complicated, I think, especially as relates to random weird edge cases in the type system (where things don't completely behave as expected).

I've updated the new isinstance checking to only be active with --strict-optional enabled so this PR doesn't have to block on #1568, which is a bit complicated.

It would be nice to have test cases for various things that have been fixed.

Docstring of NoneTyp doesn't seem to be up to date:

    """The type of 'None'.

    This is only used internally during type inference.  Programs
    cannot declare a variable of this type, and the type checker
    refuses to infer this type for a variable. However, subexpressions
    often have this type. Note that this is not used as the result
    type when calling a function with a void type, even though
    semantically such a function returns a None value; the void type
    is used instead so that we can report an error if the caller tries
    to do anything with the return value.
    """

I'd like a more detailed docstring for UninhabitedType. For example, it could answer questions like these:

• Why do we have this type? What is is used for?
• What is it's relationship with NoneTyp?
• Why isn't this called the bottom type? Is it somehow different from a bottom type? If not, mention that this is the same as bottom type.
• How do various type operations work with NoneTyp? For example, how do meet, join and subtyping work? I think it's worth describing them here (but not in too much detail) as the type is a little unusual.
• Can a variable have this type as its inferred type?

Also, add unit tests to mypy/test/testtypes.py that test various type operations with UninhabitedType.

One additional thing to test: see if overloaded functions work with None. If this doesn't work, it's okay to create a separate issue for it.

This is good to rebase and land after resolving the 'Need type annotation for variable' issue.