Best practice for dealing with Optional Parameters in Script Tools?

752
14
Jump to solution
10-26-2021 11:09 AM
ZacharyHart
Regular Contributor

Here's a crude example to at least put forth some effort in asking this question. I tried searching and got some results but I fear my inquiry is too simplistic to find viable results.

Let's say we have just two parameters defined in the code; and in the script tool we have configured parameter 1 to be 'required' and parameter 2 to be 'optional'.

 

 

RequiredParameter = arcpy.GetParameterAsText(0)
OptionalParameter = arcpy.GetParameterAsText(1)

 

 

So if your code has a line expecting OptionalParameter, the script will fail. So how best to evaluate it being supplied by the user or not?

A few options I have found:

Evaluate for presence of the optional parameter:

 

 

if OptionalParameter and OptionalParameter != "#":
    #Do something with optional parameter

 

 

Try-Except block:

 

 

try:
    #arcpy tool using the supplied optional parameter
except:
    pass #move on with life never knowing if anything went wrong or why it did

 

 

 I suppose something could be done within the script tool validation, but the code itself would have to be modified as well.

Pitfalls of either? Better options exist?

0 Kudos
14 Replies
ZacharyHart
Regular Contributor

Can anyone attest to the veracity of this statement here?

"The hash sign ("#") string is what the geoprocessing framework passes in for unspecified values so you have to look for that in addition to the empty/null string case."

stack exchange link

I ask because I noticed no one suggesting testing for != "#"

0 Kudos
JeffK
by MVP Regular Contributor
MVP Regular Contributor

Maybe it was a thing back in '13 but I haven't seen any parameter come through as '#' so could be outdated?  

BlakeTerhune
MVP Regular Contributor

I've seen some of the Esri GP tools do this. When you run the tool and then copy the Python snippet, it'll put "#" for the optional parameters that were left empty. I have never done this explicitly with my Python toolboxes and I don't see a need for it.

DanPatterson
MVP Esteemed Contributor

I prefer `named` parameters rather than positional parameters, particularly for those that are optional.

More of a notation, than a solution, but assume the `funk` is a script associated with a tool.  I have omitted error checking for the first two parameters to ensure that they have values (type hints can be used but that is another story.

So assume, that I pass the tool the tool 4 parameters (use GetParameter or GetParameterAsText if you want to check for None as 'None')

def funk(req1, req2, **kwargs):
    """kwargs are optional named parameters.  I prefer `named` parameters."""
    opt1 = kwargs.get('opt1', None)
    opt2 = kwargs.get('opt2', None)
    args = [req1, req2, opt1, opt2]
    return  args
    

out = funk(1, 2, opt2=3)

print(out)
[1, 2, None, 3]

note that the optional parameter (opt1) is checked for its existence (aka, it was named in the call to the script).

In `custom` python toolboxes you can set default values for your parameters like "None", "nothing to see here", "zilch".... whatever, then test for it in your scripts.  Avoid blanks or "" or '' because they all look the same, put in a default "null/ignore me" value.  You will thanks yourself in a year or two when you have to figure out what you did


... sort of retired...
ZacharyHart
Regular Contributor

Thanks everyone I really learned a lot from this!

0 Kudos