I’ve also been annoyed by this need for verbosity and like this solution. introducing the new special keyword as could case knock-on effects I’m not experienced enough to evaluate so could be a hard sell.
an alternative could be to apply the annotation across all assignments, so you could write:
When the need for explicit type declarations becomes a burden and a PITA, we should consider not using explicit type declarations.
I don’t know how mypy operates, but some type systems are perfectly capable of inferring types.
I argue that we should never have to declare the type of a variable bound to a constant: a: int = 1 is awful. If a = 1 of course it’s an int what else could it be?
We should only need to annotate a variable assignment if we want to loosen the inferred type, e.g. a: Any = 1. We should not have to repeat the information already there in the assignment.
(I’ll also argue that using types for physical units is the wrong solution, but that’s an argument for another day.)
But if we did decide that it would be useful to have block declarations, I suggest that there’s no need for new syntax. We could add a context manager to the typing module:
rvp = ...
rcs = ...
and have the static checker recognise that pattern.
One downside of this is I’m not sure how easy it would be for the context manager to populate the __annotations__ dict. Here’s a sketch of a solution:
if the context manager is not running in the global scope, do nothing.
otherwise, on entry, take a snapshot of all the global variable names: snapshot = set(globals().keys())
on exit, compare that snapshot to the current globals, and annotate any new variables:
for name in globals().keys() - snapshot: annotations[name] = The_Type
Note that this is not thread-safe: another thread could create a global, and the context manager would then wrongly annotate it on exit. But only the main threads should create globals, so this is a very small risk.
Is the specific problem that you have a type whose name or definition is really long and so you don’t want to have to take up space/type out the expression for several lines? Because if so, we can already shorten type names using TypeAlias.
If the remaining problem is just needing to write the same type annotation for many closely related variables (as it looks like in your OP), I would argue a cleaner pattern is to put them in a data structure like a dict, and then you can specify the type for all of the keys at once.
I really like this suggestion, thanks for giving such a thought out answer. I think that would definitely be the way to go, but i was curious what alternatives to types you’d recommend for physical units?
Side note, the variables in our project are loaded from a file and this obfuscates the type ( which is why type hinting seemed beneficial )
PEP 591 (“Adding a final qualifier to typing”) is irrelevant to my point about having to annotate variables where the type can be inferred. Annotating a variable as “Final” (i.e. a constant which should not be rebound) is not the same as annotating a value which is clearly and obviously an int as an int.
mypy correctly infers the types of a, b and c here:
a = len("hello")
b = 1234
c = b//2
def func(m:int, n:int) -> int:
return m + n