This is a prelude to fixing type errors in environment.py.
One of the big sources of type errors so far has been the fact that environment.get_value() is ~untyped. Many places in the codebase assume that it returns e.g. a string, or an int. We can introduce get_value_int() for example for ints that checks at runtime that the environment variable evaluated to an int, and use that instead where applicable to appease the
type checker (and surface errors earlier at runtime).
There is a need for a get_value_string() that tries to evaluate environment variable contents, i.e. supports quoted values. Many variables are expected to be strings, yet the pervasive use of environment.get_value() and environment.set_value() means it is hard to tell whether they are sometimes quoted or not.
This PR renames the current get_value_string() function to make space for a future get_value_string() that evaluates variables.
This is a prelude to fixing type errors in
environment.py
.One of the big sources of type errors so far has been the fact that
environment.get_value()
is ~untyped. Many places in the codebase assume that it returns e.g. a string, or an int. We can introduceget_value_int()
for example for ints that checks at runtime that the environment variable evaluated to an int, and use that instead where applicable to appease the type checker (and surface errors earlier at runtime).There is a need for a
get_value_string()
that tries to evaluate environment variable contents, i.e. supports quoted values. Many variables are expected to be strings, yet the pervasive use ofenvironment.get_value()
andenvironment.set_value()
means it is hard to tell whether they are sometimes quoted or not.This PR renames the current
get_value_string()
function to make space for a futureget_value_string()
that evaluates variables.