Optional does not remove de need for a defualt value. The default is shown to the user in the UI, so the UI must be able to somehow retrieve that value. I think an optional value is just one that can accept a None valu (or not be present when calling the algorihtm, so it can be omitted), so it's more in terms of syntax

the problem i see is that the meaning of "optional" might not be the same for all types of parameters. For instance, an extent can really be "optional", meaning that, the algorithm can run without it. If you have a extent parameter called "Crop result to extent", if you do not add it, it does not crop anythin but the algorithm runs normally. For a number value, like the "buffer distance" in a buffer algorithm, optional means "use whatever default value you have", but still that value is needed. It cannot be None.

All numerical values in the current algorithms are like that. That's the reason why there were no optiona numbers before, but i added them as requested, and the same for other types of parameters. But the meaning of being optional is not exactly the same in all cases

Would you agree that the concept of optional in general is to ask the algorithm to do whatever it thinks is best? This can depend on the algorithm and parameter obviously. Just what happens if an external binary is called without specifying a particular parameter.

Anyway, do you agree that the behavior should be the following?

• If a parameter is optional and None is given: omit it.
• If a parameter is not optional and None is given: use the default.

"If a parameter is not optional and None is given: use the default."

That not the case in parameters such us layers or tables (the only ones that were optional at first). If it's not optional (like a DEM in a Slope algorithm), None is not allowed, there must be a valid layer, otherwise it throws an exception. In this case, there is no default

Other than that, what you propose makes sense

Does it make sense for other parameters to define None as default value for non-optional parameters?
Or can they all throw exceptions in this scenario?

They all should throw exceptions if None is not a valid value...and there is no default value to resort to in that case

Thanks @volaya
@rldhont do you agree with this? Can you take care of that?

Glad the tests already discovered something :)

Hi @m-kuhn and @volaya,

To be sure, I'd like to resume the comportement if value is set to None:

• For non-optionnal parameter without default value (layer, table, etc): throw an exception
• For non-optionnal parameter with default value (String, Number, etc): set value to default ? or throw an error ?
• For optionnal parameter with default value: set value to default ? or to None ?
• For optionnal parameter without default value: set value to None

I'm not sure to have well understand what you should when a parameter has a default value.

I'm working on improving the test coverage of the parameters module, and am interested in incorporating the results of this discussion.

Just from a code standpoint, I don't get why "optional" parameter is given a default value when the user has assigned it to be None. That's not optional per se, it's just optional for the user to specify it. It will always have a value, it just might be the default specified in the constructor. If you are saying that you want it to be "optional" for the user to specify, but it must always have some Value can that be accomplished by making it required and have a default?

Examples are helpful - Do any algorithms come to mind that use these parameters in this interesting way?

Aren't we mixing up parameter type and parameter here?

I'm making the following example up, just to show the point but don't blame me on them

• A parameter type CRS can be optional or have a default
• An algorithm reproject does have a parameter (of type CRS) target CRS. This is not optional and can have a default of 4326 (meaning: if not specified otherwise)
• An other algorithm rasterize does have a parameter (of type CRS) target CRS. This is optional as in: if unspecified it will be taken from the source layer.

I don't see why different parameter types should handle optional and default values differently. It should be possible to specify a default for all of them (although it doesn't make much sense for a layer, but why prohibit it?) and to make them all optional.

Disclaimer: I've never written a processing plugin 😊

Aren't we mixing up parameter type and parameter here?

I'm not sure what you mean. Are you trying to distinguish between processing.core.parameters.Parameter() and processing.core.parameters.Parameter().value ?

And neither did I 😊

I am trying to distinguish between the class processing.core.parameters.Parameter (as in paramter type) and an instance of it (as in parameter).

The class should support the concept of being optional while each instance can be tagged if it is optional.

Sorry but I'd like to know if we have to update the way Processing manage optional parameter.

I'd like to know how to manage set value :

• For non-optionnal parameter with default value (String, Number, etc): set value to default ? or throw an error ?
• For optionnal parameter with default value: set value to default ? or to None ?

Second question, for which parameter type do you think Processing not well manage set value to None ?

Actually, I do not feel authoritative for this at all. I'd really appreciate @volaya to take the decision.

I've made explicit some of the optional/default behavior in #2541

See the various testOptional methods.

For the record, I met @rldhont last week at the Frech QGIs meeting adn we discussed about this. He will write down the cases and how parameters should behave, according to that discussion, and put it here so you can check it, and I will implement that.

The rationale is that the design of parameters was mainly conceived for using Processing from QGIS desktop (toolbox, console, etc), but for the case of using it in the server (WPS), the situation is a bit different,, as he is finding out. Changes are not likely to affect the desktop interface or break stuff, but will allow him to have a better implementation on the server side. Hopefully, they will not look counterintuitive on the desktop side of things.

Hi @volaya @michaelkirk and @m-kuhn

Here is the way, I think, the setValue method has to be:

    def setValue(self, obj):
        if obj is None:
            self.value = self.default
            if not self.optional and self.default is None:
                return False
            return True
        self.value = unicode(obj)
        return True

I think that if the parameter's value is set to None the value has to be the default one and this set is valid (return True) if the parameter is optional or if the parameter is not optional but with a not None default value.

This can be applied to all parameters:

Are-you agree with all of these ?

Waiting for the comments of @m-kuhn and @michaelkirk, but that sounds good to me. Pity that we cannot use that code snippet for the parent Parameter class (since there are specific checks for each parameter type), but it should be an easy work to adapt the parameters module to this. I will work on it if no one says anything against it

Thanks for the nice summary!

Started working on this. Have a minor comment.

What happens if the default is a not-None value (let's say, for a crs parameter, the default is "EPSG:4326") but the user wants to set None as the value (for instance, to indicate that there is no need to use any CRS for reprojecting the output)?

I think that this is a corner case, and probably be handled with a subclass of the ParameterXXX class, but just wanted to mention it.

Nice list @rldhont . I'd say this should go into the documentation somewhere so this work is not in vain.

Concerning the snippet: If False is returned, I would suggest the value should not be changed at all.

@volaya Can we use this in the parent class and implement a setValueCheck method only where required in subclasses which is called from the default setValue method?

Or overwrite setValue it in subclasses to do the check and then call the parent's default implementation?

@volaya I think the None value is used ambiguously: For "not set" and for "set default". There should probably be a value Parameter.default or similar that can be used to explicitly specify using the default value.

None should be reserved for "not set". For mandatory (non-optional) parameters None can be treated as Parameter.Default or even better (if it doesn't break existing code) an exception could be thrown : "You are trying to set None on a mandatory parameter: bad idea!".

good catch @m-kuhn. All parameters shoud have a parameter.default value, so instead of using None, one could do param.setValue(param.default), and leave setValue(None) to indicate that the parameter doesnt have a value and should not be used (which would return false if the parameter is mandatory).

That was more or less how it was before, i think... I would let @rldhont comment on this approach. I find it easier to understand, but not sure if it might cause some issues in the QGIS server side.

Thanks @volaya and @m-kuhn for your review.

Firstly, what about set value to the default one during instantiation ?

@volaya for crs parameter, the default value can be None, because if the parameter is optional he can not be set.
@m-kuhn, I think that do a setValue to None is equal to reset value to default. And setValue returns if the setValue done is valid for running the algorithm.
For me the problem with not modifying value when None is passed, is that the parameter will stay at the previous value. It will never arrive in the UI, but can be do in python script.

I think I'm repeating what @m-kuhn described, but just to reiterate maybe:

param.setValue(arg) should do one of two things -

1.) When the arg is valid*, set the param.value, return true (this may entail mutating the arg, e.g. extent parameter )
2.) When the arg is invalid, don't touch param.value, return false

*Validity is described by the ParameterType (e.g. a NumberParameter should get a number value) and optionality (setting None to a required type is invalid).

The way to reset the default should be param.setValue(param.default) or we could add a param.setDefaultValue if we want to get fancy. Equating param.setValue(None) to param.resetDefaultValue is not intuitive.

Thanks for putting this extensive table together @rldhont. I think executable test cases are a good form of documentation for something like this. I've spelled out some of the test cases in #2541, consider using it as part of your changes @volaya.

+1 for bundling this with #2541

So, to make it clear, the proposal in the last comment by @michaelkirk ...would that be ok for you, @rldhont ? I find it to be intuitive and nice

If in the server side you need to set the default if None is passed, you can put that logic outside of Processing itself, in the server code, and if the value is None, call param.setDefaultValue()

Another thing we can do is to expose a method param.checkValidity(value), so you can check the validity of a value for a given parameter, without changing its current value

That might add some extra code to the server side, but it will leave the implementation in Processing much clearer and more intuitive.

@m-kuhn, @michaelkirk: opinions?

For server side, I use Processing.runAlgorithm(alg, None, args) and I need that some input has None value. So If we add checkValidity or setDefaultValue, I'll update this method.

@volaya, @m-kuhn and @michaelkirk: how we organize us ?
First merge #2541 ? Then add CheckValidity and setDefaultValue ? At last update rumAlgorithm ?

I'd say start with setDefaultValue() and runAlgorithm() in this PR, then merge #2541 into this PR and make sure the two are compatible. Not sure about checkValidity() afaics it's an optional added value which can easily be added later?

Thank you all for your work!

@rldhont if you'd like to update the test cases as you go, I'd suggest first merging #2541. Otherwise, I'm happy to help with updating the test cases to reflect the new behavior.

To continue the discussion, you'll find proposal code at the PR #2590 [Processing] Manage default value for parameter