
## Summary Quoting from the newly added comment: Module-level globals can be mutated externally. A `MY_CONSTANT = 1` global might be changed to `"some string"` from code outside of the module that we're looking at, and so from a gradual-guarantee perspective, it makes sense to infer a type of `Literal[1] | Unknown` for global symbols. This allows the code that does the mutation to type check correctly, and for code that uses the global, it accurately reflects the lack of knowledge about the type. External modifications (or modifications through `global` statements) that would require a wider type are relatively rare. From a practical perspective, we can therefore achieve a better user experience by trusting the inferred type. Users who need the external mutation to work can always annotate the global with the wider type. And everyone else benefits from more precise type inference. I initially implemented this by applying literal promotion to the type of the unannotated module globals (as suggested in https://github.com/astral-sh/ty/issues/1069), but the ecosystem impact showed a lot of problems (https://github.com/astral-sh/ruff/pull/20643). I fixed/patched some of these problems, but this PR seems like a good first step, and it seems sensible to apply the literal promotion change in a second step that can be evaluated separately. closes https://github.com/astral-sh/ty/issues/1069 ## Ecosystem impact This seems like an (unexpectedly large) net positive with 650 fewer diagnostics overall.. even though this change will certainly catch more true positives. * There are 666 removed `type-assertion-failure` diagnostics, where we were previously used the correct type already, but removing the `Unknown` now leads to an "exact" match. * 1464 of the 1805 total new diagnostics are `unresolved-attribute` errors, most (1365) of which were previously `possibly-missing-attribute` errors. So they could also be counted as "changed" diagnostics. * For code that uses constants like ```py IS_PYTHON_AT_LEAST_3_10 = sys.version_info >= (3, 10) ``` where we would have previously inferred a type of `Literal[True/False] | Unknown`, removing the `Unknown` now allows us to do reachability analysis on branches that use these constants, and so we get a lot of favorable ecosystem changes because of that. * There is code like the following, where we previously emitted `conflicting-argument-forms` diagnostics on calls to the aliased `assert_type`, because its type was `Unknown | def …` (and the call to `Unknown` "used" the type form argument in a non type-form way): ```py if sys.version_info >= (3, 11): import typing assert_type = typing.assert_type else: import typing_extensions assert_type = typing_extensions.assert_type ``` * ~100 new `invalid-argument-type` false positives, due to missing `**kwargs` support (https://github.com/astral-sh/ty/issues/247) ## Typing conformance ```diff +protocols_modules.py:25:1: error[invalid-assignment] Object of type `<module '_protocols_modules1'>` is not assignable to `Options1` ``` This diagnostic should apparently not be there, but it looks like we also fail other tests in that file, so it seems to be a limitation that was previously hidden by `Unknown` somehow. ## Test Plan Updated tests and relatively thorough ecosystem analysis.
4.3 KiB
del
statement
Basic
a = 1
del a
# error: [unresolved-reference]
reveal_type(a) # revealed: Unknown
# error: [invalid-syntax] "Invalid delete target"
del 1
# error: [unresolved-reference]
del a
x, y = 1, 2
del x, y
# error: [unresolved-reference]
reveal_type(x) # revealed: Unknown
# error: [unresolved-reference]
reveal_type(y) # revealed: Unknown
def cond() -> bool:
return True
b = 1
if cond():
del b
# error: [possibly-unresolved-reference]
reveal_type(b) # revealed: Literal[1]
c = 1
if cond():
c = 2
else:
del c
# error: [possibly-unresolved-reference]
reveal_type(c) # revealed: Literal[2]
d = [1, 2, 3]
def delete():
del d # error: [unresolved-reference] "Name `d` used when not defined"
delete()
reveal_type(d) # revealed: list[Unknown | int]
def delete_element():
# When the `del` target isn't a name, it doesn't force local resolution.
del d[0]
print(d)
def delete_global():
global d
del d
# We could lint that `d` is unbound in this trivial case, but because it's global we'd need to
# be careful about false positives if `d` got reinitialized somehow in between the two `del`s.
del d
delete_global()
# Again, the variable should have been removed, but we don't check it.
reveal_type(d) # revealed: list[Unknown | int]
def delete_nonlocal():
e = 2
def delete_nonlocal_bad():
del e # error: [unresolved-reference] "Name `e` used when not defined"
def delete_nonlocal_ok():
nonlocal e
del e
# As with `global` above, we don't track that the nonlocal `e` is unbound.
del e
del
forces local resolution even if it's unreachable
Without a global x
or nonlocal x
declaration in foo
, del x
in foo
causes print(x)
in an
inner function bar
to resolve to foo
's binding, in this case an unresolved reference / unbound
local error:
x = 1
def foo():
print(x) # error: [unresolved-reference] "Name `x` used when not defined"
if False:
# Assigning to `x` would have the same effect here.
del x
def bar():
print(x) # error: [unresolved-reference] "Name `x` used when not defined"
But del
doesn't force local resolution of global
or nonlocal
variables
However, with global x
in foo
, print(x)
in bar
resolves in the global scope, despite the
del
in foo
:
x = 1
def foo():
global x
def bar():
# allowed, refers to `x` in the global scope
reveal_type(x) # revealed: Literal[1]
bar()
del x # allowed, deletes `x` in the global scope (though we don't track that)
nonlocal x
has a similar effect, if we add an extra enclosing
scope to give it something to
refer to:
def enclosing():
x = 2
def foo():
nonlocal x
def bar():
# allowed, refers to `x` in `enclosing`
reveal_type(x) # revealed: Literal[2]
bar()
del x # allowed, deletes `x` in `enclosing` (though we don't track that)
Delete attributes
If an attribute is referenced after being deleted, it will be an error at runtime. But we don't
treat this as an error (because there may have been a redefinition by a method between the del
statement and the reference). However, deleting an attribute invalidates type narrowing by
assignment, and the attribute type will be the originally declared type.
Invalidate narrowing
class C:
x: int = 1
c = C()
del c.x
reveal_type(c.x) # revealed: int
# error: [unresolved-attribute]
del c.non_existent
c.x = 1
reveal_type(c.x) # revealed: Literal[1]
del c.x
reveal_type(c.x) # revealed: int
Delete an instance attribute definition
class C:
x: int = 1
c = C()
reveal_type(c.x) # revealed: int
del C.x
c = C()
# This attribute is unresolved, but we won't check it for now.
reveal_type(c.x) # revealed: int
Delete items
Deleting an item also invalidates the narrowing by the assignment, but accessing the item itself is still valid.
def f(l: list[int]):
del l[0]
# If the length of `l` was 1, this will be a runtime error,
# but if it was greater than that, it will not be an error.
reveal_type(l[0]) # revealed: int
# error: [invalid-argument-type]
del l["string"]
l[0] = 1
reveal_type(l[0]) # revealed: Literal[1]
del l[0]
reveal_type(l[0]) # revealed: int