Can f-strings be used in script tools?

[ChrisGAEG]

Can script tools use f-strings? I'm getting an 'ERROR 000354: The name contains invalid characters'.  The line that is causing the error is as follows - 

arcpy.FeatureClassToFeatureClass_conversion('Proposed_OLT_LCP_Boundaries', scratch, f'{lcpNameFixed}_Boundary', exp)

 Here is how lcpNameFixed is assigned. 

lcps = arcpy.GetParameterAsText(0)

lcpNameFixed = lcp.replace('-', '')

 The value list of lcps has dashes ('-') but the lcpNameFixed takes the dashes out. The lcps value list doesn't start with numbers either.  I just want to rule out if the f-string might be causing this invalid name error. 

[emedina · Accepted solution]

I'd say your answer is "Yes" provided you're using the script tools with environments at version 3.6+ of Python. If you're reasonably sure no one's using a version older than that then your tools should be fine. However, if you want to ensure compatibility with older versions then you're stuck with .format, I guess.

[ChrisGAEG]

Correct, I found that one of my layers had a '/' in the name. 😅  F-strings can be used in line as arguments. Thanks for the response. 

[Cristian_Galindo]

Do you mean Pyhton 3.6+?

I can say for experience that some of the arcpy tools in Python 3.7 (ArcGIS Pro 2.9) that some of the tools accept f-string as parameters other does not:

This example does not work (using the f-string in the where_clause parameter):

where_clause_with_date_filter = f"{where_clause} AND {date_filter}"
points_select = arcpy.analysis.Select("{0}.{1}".format(schema_owner, TABLE_CAL_POINTS), r"memory\f{0}".format(uuid4().hex),where_clause_with_date_filter)

generates the error:

  File "C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\Resources\ArcPy\arcpy\analysis.py", line 138, in Select
    raise e
  File "C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\Resources\ArcPy\arcpy\analysis.py", line 135, in Select
    retval = convertArcObjectToPythonObject(gp.Select_analysis(*gp_fixargs((in_features, out_feature_class, where_clause), True)))
  File "C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\Resources\ArcPy\arcpy\geoprocessing\_base.py", line 512, in <lambda>
    return lambda *args: val(*gp_fixargs(args, True))
arcgisscripting.ExecuteError: ERROR 000358: Invalid expression f"{where_clause} AND {date_filter}"
Failed to execute (Select).

i have tried to use the f-string in search cursor, and update cursor and found that in the feature_class parameter,m it does not accept f-strings, but in the where_clause it does:

with arcpy.da.UpdateCursor("{0}.{1}".format(schema_owner, TABLE_LINKAGES),
                                   ["REFERENCE_FEATURE_ID"],
                                   where_clause=f"PROJECT_ID = '{project_id}'") as cursor:

[DanPatterson]

f"{}"  == "{}".format()

However, the f-strings have almost implemented all the capabilities of the .format version. 

For the casual/infrequent user, it is sometimes a preference between pre-fix versus post-fix notation.

For others it is the onerous task of typing the extra "ormat".

In any event, all variables/strings passed to either case needs to be raw-encoded at source prior to formatting to avoid nasty unexpected errors.

Try this on.

b ="{}".format(r"Ooops\a\b\t")
b
'Ooops\\a\\b\\t'
# ---- or
a = r"Ooops\a\b\t"
f"{a}"
'Ooops\\a\\b\\t'

# ----- now, omit raw encoding
c ="{}".format("Ooops\a\b\t")
c
'Ooops\x07\x08\t'
# --- etcetera

[ChrisGAEG]

Onerous indeed. Thanks again for the clarification Dan! 

[MattHowe]

They can in main scripts but I've noticed validation scripts don't like them.

[RyanDavis1]

I'll add that I've noticed the consolidation and packaging tools tend to convert f-strings to .format and then assign them to g_ESRI_variables.  No idea why.

Generally speaking, I have little problem with f-strings but every so often Pro [2.6] returns an error.  Sometimes it's solved by simply closing the program and re-opening.  It seems really inconsistent.

[DanPatterson]

f strings are largely shortcuts to "".format .  there is no "real" advantage to using them and the capabilities of "format" haven't been completely replicated in f-strings.  Some people claim they are shorter but in reality most cases are only shorter by "ormat" characters 😉

[MattHowe]

Totally agree. I find using them to create definition queries in scripts easier but more than anything I think they make code a bit easier to read for people new to Python.