{"id":269,"date":"2014-11-25T15:50:27","date_gmt":"2014-11-25T21:50:27","guid":{"rendered":"http:\/\/cartometric.com\/blog\/?p=269"},"modified":"2014-11-25T16:04:53","modified_gmt":"2014-11-25T22:04:53","slug":"arcpy-calculatefield_management-complex-python-expression-to-return-a-string","status":"publish","type":"post","link":"https:\/\/elrobis.com\/blog\/2014\/11\/25\/arcpy-calculatefield_management-complex-python-expression-to-return-a-string\/","title":{"rendered":"ArcPy CalculateField_management Complex Python Expression to Return a String"},"content":{"rendered":"

My coworker was having some trouble implementing a CalculateField expression in Python so I wanted to document the solution for anyone with a similar issue. (Note: If you\u00a0 just want the answer, see the What ultimately worked..<\/em><\/span> heading, below.)<\/p>\n

Being unfamiliar with ArcPy, I was intrigued by this idea of defining a function as a string value, then passing that string as a variable into another function. I can see how that opens a powerful door\u2014but it also strikes me as ultra weird, and because Python has some very particular spacing\/indentation rules (as compared to say, JavaScript), I figured this technique would be ultra-prone to syntax issues ..and thus could be especially difficult to troubleshoot. So in this case, I also wanted to demonstrate how I ultimately thought through the problem.<\/p>\n

After some quick Googling, we found two<\/a> relatively useful pages<\/a> of documentation in the ESRI support ecosystem, and both pages demonstrated different ways to formulate the function-as-string<\/code> parameter necessary for the CalculateField_management()<\/code> function.<\/p>\n

The biggest difference between these examples is how they portrayed line breaks in the function-as-string<\/code>; we’ll consider them first.<\/p>\n

 <\/p>\n

The first example..<\/h2>\n

In the first ESRI example, the\u00a0function-as-string<\/code> was concatenated together across multiple lines using a backslash \\<\/code> like this..<\/p>\n

codeblock = \"def getclass(area):\\ \r\n        if area <= 1000:\\ \r\n            return 1\\ \r\n        if area > 1000 and area <= 10000:\\ \r\n            return 2\\ \r\n        else:\\ \r\n            return 3\" \r\n\r\nprint codeblock<\/span><\/pre>\n
Realizing Python is very picky about syntax, I wanted to see what happened if I print codeblock<\/code>\u00a0 to the console\u2013notice that spacing is preserved, but there are no line breaks:<\/p>\n
\"\"<\/p>\n
Frankly, it’s difficult for me to believe this was ever a working example, and surprise\u2014this approach didn’t end up working for us..<\/p>\n
 <\/p>\n
And the second example..<\/strong><\/h2>\n
In the second ESRI example, the\u00a0function-as-string<\/code> was concatenated together across multiple lines using triple-quotes \"\"\"<\/code> to declare a multiline string, like this..<\/p>\n
codeblock = \"\"\"def getClass(area):\r\n    if area <= 1000:\r\n        return 1\r\n    if area > 1000 and area <= 10000:\r\n        return 2\r\n    else:\r\n        return 3\"\"\"\r\n\r\nprint codeblock<\/span><\/pre>\n
Similarly, I wanted to codeblock<\/code> to the terminal to see how the string was formatted before going into the ArcPy function; this time, the linebreaks were preserved:<\/p>\n
\"\"<\/p>\n
..that looks more like a Python function, so that was a good start. But things still weren’t working..<\/p>\n
 <\/p>\n
How to test our custom function..?<\/strong><\/h2>\n
We were still getting errors, and the stack dump claimed they were syntax errors. But because of the unusual nature of this software design, I wasn’t sure if they were really<\/em> syntax errors, or some kind of misleading, catch-all error ..perhaps our code-in-a-string<\/code> function was flawed?<\/p>\n
So my next step was to test our function, as a legit Python function, to see if it would accept and return a value like I expected.<\/p>\n
def getClass(area):<\/span>\r\n\u00a0\u00a0\u00a0 if area <= 1000:<\/span>\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return 1<\/span>\r\n\u00a0\u00a0\u00a0 if area > 1000 and area <= 10000:<\/span>\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return 2<\/span>\r\n\u00a0\u00a0\u00a0 else:<\/span>\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return 3<\/span>\r\n\r\nprint getClass(1500)<\/span><\/pre>\n
As you can see, the code ran without any syntax errors..<\/p>\n
\"\"<\/p>\n
Also, 2 is the correct return value for the input we used in the test. So I felt comfortable that the function itself\u2014as written\u2014worked. So now I was perplexed as to why the ESRI CalculateField_management()<\/code> function was rejecting it ..with a syntax error.<\/p>\n
 <\/p>\n
What ultimately worked..<\/h2>\n
My co-worker’s function had another gotcha\u2014unlike the two ESRI examples, which return numeric values, we needed our function to return a string. My Python was rusty, and I was forgetting if a string could be declared equally between single quotes i.e. 'MyString'<\/code> and\u00a0<\/code>double quotes, i.e.\u00a0 \"MyString\"<\/code>. Plus, I still new we were looking for an alleged syntax<\/em> error.<\/p>\n
I finally Googled a third page in the ESRI documentation<\/a> and noticed this little tidbit in some ESRI documentation:<\/p>\n
Python enforces indentation as part of the syntax. Use two or four spaces to define each logical level. Align the beginning and end of statement blocks, and be consistent.<\/p><\/blockquote>\n
My coworker had originally used one and two spaces, respectively, to control indentation in his custom function, along with the first technique for declaring a multiline string. So I finally rewrote our function using the triple-quotes technique as well as 2 and 4 space indents like ESRI said to, and this is what we ended up with..<\/p>\n
For the record, while a large if<\/code>\/elseif<\/code> block may not be the best way to write this function, it is a very readable<\/em> way to write this function, not to mention the most intuitive from my coworker’s perspective.<\/p><\/blockquote>\n
codeblock = \"\"\"def getclass(SPEEDLIM):<\/span>\r\n\u00a0 if SPEEDLIM >= 60:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A10'<\/span>\r\n\u00a0 elif SPEEDLIM == 55:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A30'<\/span>\r\n\u00a0 elif SPEEDLIM == 50:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A20'<\/span>\r\n\u00a0 elif SPEEDLIM == 45:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A30'<\/span>\r\n\u00a0 elif SPEEDLIM == 40:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A30'<\/span>\r\n\u00a0 elif SPEEDLIM == 35:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A40'<\/span>\r\n\u00a0 elif SPEEDLIM == 30:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A00'<\/span>\r\n\u00a0 elif SPEEDLIM == 20:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A00'<\/span>\r\n\u00a0 elif SPEEDLIM == 15:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A00'<\/span>\r\n\u00a0 elif SPEEDLIM == 10:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A61'<\/span>\r\n\u00a0 elif SPEEDLIM == 5:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A62'<\/span>\r\n\u00a0 elif SPEEDLIM <= 5:<\/span>\r\n\u00a0\u00a0\u00a0 return 'A71'\"\"\"<\/span><\/pre>\n
And this worked. I think the fix resulted from using triple-quotes to declare the function string, rather than the backslash approach we started with.<\/em> While we also changed the indentation to use 2\/4-spaces, as mentioned above, it’s possible we unwittingly fixed a different syntax error in the function along the way. Since we didn’t make these changes independently, it’s impossible to know which exactly<\/em> made the difference.<\/p>\n
 <\/p>\n
Summary<\/h2>\n
So this is a summary that might help you if you’re having difficulty with this kind of ArcPy data management exercise:<\/p>\n
    \n
  • Try writing a basic version of your function in a throw-away .py file and test it to make sure it definitely works\u2014if nothing else, this is a good sanity check<\/em>.<\/li>\n<\/ul>\n
      \n
    • Make sure to use the triple-quote technique to properly preserve line breaks, and declare your function as a string variable that you can pass into your call to the geoprocessor. (You may need to use single-quotes to declare any strings within your larger, multiline string, which was the technique we used.)<\/li>\n<\/ul>\n
        \n
      • If things still aren’t working, try using increments of 2 spaces to control various levels of indentation within your custom function, i.e. 2\/4\/6\/8\/etc..<\/li>\n<\/ul>\n
        Hopefully that helps you get where you’re trying to go.<\/p>\n
        Baaaaaaaaaaaaaaaaaaaaaaaaaaammmmm!!!!<\/p>\n
        – elrobis<\/p>\n
        <\/pre>\n","protected":false},"excerpt":{"rendered":"
        My coworker was having some trouble implementing a CalculateField expression in Python so I wanted to document the solution for anyone with a similar issue. (Note: If you\u00a0 just want the answer, see the What ultimately worked.. heading, below.) Being unfamiliar with ArcPy, I was intrigued by this idea of defining a function as a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[39,27,43],"tags":[],"_links":{"self":[{"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/posts\/269"}],"collection":[{"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/comments?post=269"}],"version-history":[{"count":7,"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/posts\/269\/revisions"}],"predecessor-version":[{"id":272,"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/posts\/269\/revisions\/272"}],"wp:attachment":[{"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/media?parent=269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/categories?post=269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/elrobis.com\/blog\/wp-json\/wp\/v2\/tags?post=269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}