Calculate Field for Zipcode values fails when there is a leading zero

Question

I've condensed my problem into this simplistic test sample, and I hope somebody out there can explain what is going on.

The attached zipfile contains an MXD with a table in the table of contents named "zip_table" that exists in the sample file geodatabase test_fgdb.gdb.  The source will probably need to be re-established on your end.  There is also a toolbox file named "Zipcode_Test.tbx" that should be added to ArcToolbox, and it makes use of the simplistic python in the script "test_zipcode.py".

When activated, the tool should request an input table ("zip_table" should be used in this case).  It then looks for the 'ZIPCODE' field, and populates it with a pre-defined string.  Currently this pre-defined string is set in the script as "01234".  But after running this tool, the value "668" is what ends up in the table.  The zipcode value is a string and I can't figure out why it looks like it's being converted into that new value.  Changing to "12345" returns the correct value in the table.  Adding characters instead of numbers has caused the script to bail completely.

This script was also converted and run in command line python outside of ArcGIS with the same results.

Is this a known bug with the arcpy module?  Does anybody know what the heck is going on here?

zipcode_test.zip

NiklasNorrthon · Answer

The solution to the mystery is that:* The python parser thinks that numbers that starts with a zero are octal
* The CalculateField function takes a string which is the parsed by the python parser

To get around you problem you must make the calculate field function understand that you don't send it a number (which will then be converted to a string), but that it is actually already a string. To do that you can say:

zipcode = "'01234'"
and then CalculateField(...,  zipcode, 'PYTHON')

The function will internally do eval(zipcode) to get a python object.

This quoting issues makes it difficult to use CalculateField from within scripts, and it's often easier just to resort to an UpdateCursor instead. That is especially true when using the code block for precalculate logic.

DanMarrier · Answer

Thanks for the reply.  I'll be giving that a try this morning.  But it still doesn't explain why the arcpy module can't interpret it as a string, especially when the value is double quoted or even if the str() function is used.

Anonymous User · Answer

import arcpy
import os

arcpy.env.workspace='C:/Temp/Python/zipcode_test/zipcode_test/test_fgdb.gdb'

#table = arcpy.GetParameterAsText(0)
#table = os.path.basename(table)
table = os.path.join(arcpy.env.workspace, 'zip_table')
fldList = arcpy.ListFields(table)
for fld in fldList:
    if fld.name == 'ZIPCODE':
      #zip_fld = fld # meaningless
      zipcode = "01234"
      arcpy.CalculateField_management(table, "ZIPCODE", "'%s'" % str(zipcode), "PYTHON")

works fine.

Edit.  Maybe I should explain.  arcpy sees zipcode = "01234" as numbers. Not sure why but if you use substitution method like "'%s'" % str(zipcode) this, it uses strings.

You can even shorten to:
import arcpy
import os
arcpy.env.workspace='C:/Temp/Python/zipcode_test/zipcode_test/test_fgdb.gdb'
arcpy.CalculateField_management(os.path.join(arcpy.env.workspace, 'zip_table'), "ZIPCODE", "'01234'", "PYTHON")