Make sure EMAworkbench outcomes and parameter names are valid Python identifiers

[EwoutH]

Make sure EMAworkbench outcomes and parameter names are valid Python identifiers

[EwoutH]

@quaquel Since you seem in quite a productive mood, would you like to also resolve this issue before releasing 2.4.1?

[quaquel]

The fix is straightforward. There is a method for it.
It needs to be done in Variable (root of uncertainties, outcomes, constants, etc.), AbstractModel (root for all model classes), and Point (root for Scenario and Policy) I guess.

Main issue is that it will break a lot of existing code (including the final assignment for epa 1361).

Would be better off in a 2.5/3.0 release.

[quaquel]

I started working on this in a branch. Constant, parameters, and outcomes now must be valid python identifiers, and this is explicitly checked. There are 2 open questions:

1. what type of exception to raise? It seems like a type error is appropriate, but I might be wrong.
2. Do we also need this for model names, and point names (i.e., scenario, policy, lever)?

[EwoutH]

1. It's not a TypeError I think, since the type can be correct (string) but it's just not a valid identified. I think a ValueError is closest, Maybe something like this?

if not name.isidentifier():
    raise ValueError(f"'{name}' is not a valid Python identifier")

2. Are these names are used in any context where they might be turned into variable names? If so, I would say yes, otherwise probably no. Except if we want it for consistency / future expandability. If that's the case, we could create in util something like

def valid_python_identifier(name):
    if not name.isidentifier():
        raise ValueError(f"'{name}' is not a valid Python identifier.")

And then just check everywhere:

class Model:
    def __init__(self, model_name, ...):
        valid_python_identifier(model_name)

If we truly want to check it everywhere, and if we can guarantee / standardize that the second variable always is the name, we could even create a decorator.

[quaquel]

1. I'll go with value error
2. I don't fully recall where the bug originated from. If I recall correctly, it was related to doing optimizations in which case model and policy would not be required to be valid Python identifiers.

[EwoutH]

Deprecated in 2.5, will be removed in 3.0 (see #337).