Why are case independent variables a list-ized dictionary and not a real dictionary

[drewj-tp]

Working with some cases lately and some workflows embed real, meaningful value in the Case.independentVariables dictionary. Simulations may rely on these data to make some modeling changes that can't be meaningfully captured in the "real" settings (the point here is not whether that is good/bad, just that it is done)

During runtime, you don't really have Case object. You just have an Operator with some settings. Workflows that need to extract then that meaningful data need to access o.cs["independentVariables"] and you are greeted with a really weird (to me) data structure. You don't have a map of variable -> value, you have a list of tuples of repr calls. One for the variable name, one for the value like

  independentVariables:
    - ('param_a', 370.0)
    - ('param_b', 500.0)
    - ('param_c', 1500.0)
    - ('param_d', 10)

To get the value of param_a, I would expect that I could do cs["independentVariables"]["param_a"]. But, because of this logic

armi/armi/cases/case.py

Lines 699 to 702 in e91f4ad

	if self.independentVariables:
	newSettings["independentVariables"] = [
	f"({repr(varName)}, {repr(val)})" for varName, val in self.independentVariables.items()
	]

Workflows need to rebuild each key/value pair.

Why? What is the value of these repr-ized representations? These seems to be in public ARMI since ever so maybe there's a good historical reason?

[drewj-tp]

Additionally, the property reader uses ast.literal_eval

armi/armi/cases/case.py

Lines 118 to 120 in e91f4ad

	for indepStr in self.cs["independentVariables"]:
	indepName, value = ast.literal_eval(indepStr)
	self._independentVariables[indepName] = value

which ... well I'll let the docs speak to why this feels not great to me

This function had been documented as “safe” in the past without defining what that meant. That was misleading. This is specifically designed not to execute Python code, unlike the more general eval(). There is no namespace, no name lookups, or ability to call out. But it is not free from attack: A relatively small input can lead to memory exhaustion or to C stack exhaustion, crashing the process. There is also the possibility for excessive CPU consumption denial of service on some inputs. Calling it on untrusted data is thus not recommended.

[drewj-tp]

Specifically, since we're rebuilding from the repr, this only really works for trivial objects. Unless you've written the __repr__ to completely describe the object. Which is usually the goal. But, consider the humble numpy.array

>>> import numpy as np
>>> v = np.arange(10)
>>> r = repr(v)
>>> r
'array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])'
>>> import ast
>>> ast.literal_eval(r)
...
ValueError: malformed node or string on line 1: <ast.Call object at 0x0000011DAAF0F290>