E.g. mylist = [None] or mydict = {k: None for k in keys}, etc. This kind of pattern occurs not-infrequently, where the container is later updated with non-None values. It seems like a good guess that the user probably doesn't intend for the container to only ever hold None.
The tricky question is what we should widen it to. We could use Unknown | None, but it feels a bit weird to introduce a gradual type just in this case.
Or we could do nothing, and users can add an annotation in these cases.
The best answer might be #1473, where if we see only None initially, we look ahead to later additions to decide what wider type to use.
We could also apply this to other singleton types (ellipsis? literals are already handled in promotion), but those cases seem likely so rare as to not really be worth caring about.
E.g.
mylist = [None]ormydict = {k: None for k in keys}, etc. This kind of pattern occurs not-infrequently, where the container is later updated with non-None values. It seems like a good guess that the user probably doesn't intend for the container to only ever holdNone.The tricky question is what we should widen it to. We could use
Unknown | None, but it feels a bit weird to introduce a gradual type just in this case.Or we could do nothing, and users can add an annotation in these cases.
The best answer might be #1473, where if we see only
Noneinitially, we look ahead to later additions to decide what wider type to use.We could also apply this to other singleton types (ellipsis? literals are already handled in promotion), but those cases seem likely so rare as to not really be worth caring about.