Consider `eval`ing property overrides
With the -P switch we can override properties, but only strings.
What if I want to override a property that takes a list value, or a boolean? For booleans you can hope the plugins checks for truthiness/falsiness only (if x) and not against actual singletons (None, False, True) but for lists or numbers there is no solution.
So it just occurred to me that we could use eval to produce actual types from the -P arguments.
This would probably break existing things built by users because writing -P my_prop=new_value would result in an unbound local error. It's possible to avoid polluting and getting polluted by scope, but we're still running unknown code (user could do this himself though, so I don't see a security problem here).
Feedback or other ideas welcome.
For -P my_prop=new\ value, what does eval(new\ value) give you? I assume it breaks. So we need to have backwards compatibility somehow that can distinguish between:
-P my_prop=new\ string\ value
and
-P "my_prop='something to eval %s' % variable"
Maybe = vs := ?
Yes new and value would be unbound locals. A new operator would be neat, but I don't think the cli parser can handle this. There's always the option of adding a new flag, like --eval-override
CLI just splits the value on =. We can always split on = or :=. Some minor coding is necessary.
Question is - when do you want to eval them, i.e. in what phase? I assume right in the invocation of @init so that the context of eval is predictable.
Hm, the := definitely sounds best when you put it like this. Thanks!
:+1:
Yes during init probably. But with no locals and globals, I think, and also keeping just the result of the eval, to avoid strange side effects.