Hi Victor,

What will happen if I expect from a python script that a variable has been defined in the project but it has not been done by the user? How will error handling happen?

I.e. is this approach precise enough to be triggered always when it's required and to not cause any unwanted side-effects.

Some ideas for alternative approaches:

Would it possibly be better to define an expression context with these variables on top of the script (just the same way import processing is injected) and a scripter could then use

QgsExpression('@some_crazy_variable').evaluate(expressionContext) # expressionContext injected into the script

Or even better a decorator for a script function that does this magic (it will less look like black magic)

@injectExpressionContext
def myScriptFunction():
    expressionContext.variable('default_resolution')

Ping @NathanW2 for all the python goodies and @nyalldawson for the expression details

@volaya seems this commit has broken the tests:

https://travis-ci.org/qgis/QGIS/jobs/125798185#L1486

Can you check the indentation?

If the variable doesn't exist, it will warn the user and the code will be executed without replacing the variable. If it fails, the error will be reported accordingly by Processing, just like it happens when there is any syntax error.

Sounds like a rather logic behaviour to me.

Other solutions might be different, but i guess that the main idea of this feature is to provide a very simple way of using variables. If the scripter needs to use some more complex code, that makes not much different to what was possible before, since you can from the script get the values of a variable using the context and scope classes.

Feel free to change the code with a different approach if you think it is more solid. This is a rather advanced functionality, and it is not documented yet, so it's quite safe to play with the implementation until we find an optimal solution.

Thanks!

Couldn't there be collisions between (@-prefixed) decorators and variable substitution?

Good catch. WE could use a different prefix, but it would be a different syntax to the regular one used in other parts of QGIS.

I guess we should think about how many people might use a decorator in a Processing script, and the odds or using a decorator with exactly the same name as one of the variables.

or make a shortcut function var('my_variable') - or even more mighty exp('3 * @my_variable')?

@NathanW2 agreed. This current approach also breaks the ability to run the script as pure python without preprocessing it.

I'd suggest adding a method in the processing utils evaluateVariable( var_name, context = None) . this method would check if an existing expression context is passed and if not, construct a new one using the global, project (and possible processing specific?) scope.