Feature: Del erases types

[Phlosioneer]

Feature

Using del on a variable (on all possible control paths, of course) removes all type info from the variable, allowing it to assume a new type when reused.

Pitch

After running into #1174, my first reaction was to use del to erase the variable's type. Nothing survives past a del so I think it's probably typesafe to erase the type info for that variable.

The main issue with variable reuse within a function body is that the variable is function-scoped, so its value (and therefore its type) last until the end of the function. When re-assigning something to that variable it's generally ambiguous whether it's a type error or whether the user is just re-using an existing name. With the del statement, that ambiguity disappears; the user is explicitly treating the value as undefined, and accessing it is a runtime error.

I wrote this code in a larger project:

if VERBOSITY >= 2:
 logDebug("DEBUG: Patch mapping:")
 for patch, jars in patchMapping.items():
 logDebug("\tPatch:",patch.name)
 # `jar` here has type `pathlib.Path`
 for jar in jars:
 logDebug("\t\t" + jar.name)
 # This is the fix I tried to use to satisfy mypy's type error
 del jar

openedJars: Dict[Path, PartiallyPatchedZipFile] = {}
 for patch, jarPaths in patchMapping.items():
 for jarPath in jarPaths:
 if jarPath in openedJars:
 jar = openedJars[jarPath]
 else:
 jar = PartiallyPatchedZipFile(jarPath)
 openedJars[jarPath] = jar
 logInfo("Applying patch", patch.name, "to", jarPath.name)
 filesMatched = applyPatch(jar, patch)
 if filesMatched == 0:
 logInfo("Warnging: Patch", patch.name, "doesn't apply to any class files in", jar.path.name)

# `jar` here has type `PartiallyPatchedZipFile`
for jar in changedJars:
 stagingJarPath = stagingDir.joinpath(jar.path.name)
 jar.writeChangesToFile(stagingJarPath)
 jar.closeZip()

In this example, mypy is technically right; if the debug code is executed, jar will be a pathlib.Path. With the del statement, the for loop's variable is cleaned up for later reuse, and jar will not contain a pathlib.Path when the second for loop begins.

Limitations

• Statements like del myDict[key] don't apply to the above logic.
• I don't know how easy/hard the control flow part is with mypy's codebase. It's not a critical part of the feature, though.
• I don't know if it applies to global values; I only reasoned about function scope.

[avylove]

I'd say this is more of a bug than a feature request.

I ran into a similar issue with something like

str_file_paths: list[str] = ...
pathlib_file_paths: list[str]...

for file_path in str_file_paths:
 ...

for file_path in pathlib_file_paths:
 filepath.name
 ...

I got an error that file_path in the second loop was a string and doesn't have a name method. It makes sense, and the intuitive thing is to add del file_path after the first loop. But MyPy remembers the type annotation it inferred on the first loop, which seems wrong given the variable was deleted.

--allow-redefinition was added in #6197, which may wok around this, but I think enabling that would be overkill and is better suited to legacy code bases. Really, I'm worried that will mask an issue.

So I'm changing the variable in the first one to file_ as a workaround, but I think this is working around a bug in MyPy rather than improving the code.