Fix --incremental crash on Type[...]

[ilevkivskyi]

This fixes the second traceback reported in #3852. This also improves member lookup on Type[...] by moving it to a later stage (checkmember.py instead of some manipulations in TypeType constructor that are dangerous during de-serialization).

By the way it looks like the first traceback reported in #3852 is just another manifestation of #3052, but instead of just deleting a class it is replaced by a Var or by a FunctionDef.

Also fixes#4058.

[gvanrossum]

Is this something urgent (fixing a regression in a recent change) that should be cherry-picked into the release branch? Or is this something that has been around for a long time? It seems the second crash in #3852 is related to pointing mypypath to site-packages, which is not recommended.

[ilevkivskyi]

Is this something urgent (fixing a regression in a recent change) that should be cherry-picked into the release branch? Or is this something that has been around for a long time?

The bug is quite old (around a year), it started to be a crash in 0.510. So I don't think it is something urgent.

It seems the second crash in #3852 is related to pointing mypypath to site-packages, which is not recommended.

The crash doesn't depend on MYPYPATH setting, but the probability to find more dynamic code in libraries is higher. For example, the crash appears on type(f) , where f is a callable other than class object.

[JukkaL]

Why does this change help? Is it because the type attribute of an Instance might refer to FakeInfo during deserialization?

[ilevkivskyi]

Yes.

[ilevkivskyi]

(Or previously to None)

[JukkaL]

LGTM. Thanks for the fix!