Can f-strings be used in script tools?

479
8
Jump to solution
07-26-2021 01:37 PM
ChrisGAEG
Occasional Contributor

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. 

0 Kudos
1 Solution

Accepted Solutions
emedina
New Contributor III

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.

View solution in original post

8 Replies
emedina
New Contributor III

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.

View solution in original post

ChrisGAEG
Occasional Contributor

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

0 Kudos
DanPatterson
MVP Esteemed Contributor

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

... sort of retired...
ChrisGAEG
Occasional Contributor

Onerous indeed. Thanks again for the clarification Dan! 

0 Kudos
Howeitzer
New Contributor III

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

0 Kudos
RyanDavis1
Occasional Contributor

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.

0 Kudos
DanPatterson
MVP Esteemed Contributor

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 ;)


... sort of retired...
0 Kudos
Howeitzer
New Contributor III

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.

0 Kudos