EOL errors when performed simple task

[IB1]

I have a field that lists numbers in the following format:

"000000-000"

But when this data was inputted, the user just copied and pasted the value from an excel sheet into the program and this caused a carriage return to be inputted with the value above.

"000000-000 "

I haven't been able to fix this problem with Python, but I can with VB which seems a bit backwards to me.

Why is Python so limited within ArcMap?

To fix this I tried multiple ways in Python, but they all failed even though they were valid.

The only way I was able to fix it was by using VB to get the length of the field for each record. So the field length should be 10 (123456-890). But with the carriage return the length for these fields returned 11, so I am able to isolate them.

So I figured, hey I'll use Python now. So I wrote the following code:

def alterField(field):     a = field[0:10]     return a

And this simple function fails in ArcMap with an EOL error.

What gives?

I ended up having to use the VB Left() function to fix it.

Python is so powerful, but so limited by ArcMap.

Why is this and will this ever be fixed?

[JasonScheirer]

You just need to use string.strip(). Just use !field!.strip() as your expression in the field calculator as Python. ArcGIS does nothing to limit the capabilities of the Python language, it's just a matter of learning it.

[curtvprice · Accepted solution]

Jason, this does not work if the string has an embedded newline.

[indent]

Executing: CalculateField "table_test" TEXTFLD !TEXTFLD!.strip() PYTHON_9.3 #
Start Time: Thu Sep 12 10:59:13 2013
ERROR 000539: SyntaxError: EOL while scanning string literal (<expression>, line 1)
Failed to execute (CalculateField).
Failed at Thu Sep 12 10:59:13 2013 (Elapsed Time: 0.00 seconds)

[/indent]

Iggz, first of all, remind your user that although Excel is a great analysis environment, it is an absolutely terrible database. (This is gospel I have been preaching to fellow researchers for decades with very limited success!)

The limitation you've run into isn't with Python but with the geoprocessing environment's inability to easily pass newlines around in arguments, even when escaped. (For example, in a Calculate Value code block you cannot include "\n" in your code, you need to use the chr() function to insert newlines in strings.) I'm willing to live with this -- because there are viable workarounds and I figure this limitation is a cost of the simplicity of having geoprocessing tools easily convert to services, and the easy similar interface tools in ModelBuilder, command line, and scripting.

More info on this issue here:
[thread=50738]End-of-line (EOL) Problem [/thread]

Generally, I have found that VBScript is less picky about its syntax, but I prefer Python's lack of ambiguity and awesome elegance, and its closer integration with ArcGIS.

Always hopeful, I tried this expression with Calculate Field with no luck, the expression string is getting garbled before it gets to the Python parser and you get the dreaded EOL error.

"""!TEXTFIELD!""".strip()

The only workaround I think is to apply this python function to your data (from the python command window, a python script, or the Calculate Value tool (this flavor of cursor is for 10.1 or later, you'll need to refactor this for pre-10.1):

def striptext(tbl, fld):
  Rows = arcpy.da.UpdateCursor(tbl, fld)
  for Row in Rows:
    Row[0] = Row[0].strip()
    Rows.updateRow(Row)

# Then, call the function like this:
striptext("mytable","TEXTFIELD")

[ATTACH=CONFIG]27402[/ATTACH]

[IB1]

You just need to use string.strip(). Just use !field!.strip() as your expression in the field calculator as Python. ArcGIS does nothing to limit the capabilities of the Python language, it's just a matter of learning it.

Oh I know Python very well. Maybe you should try what you're preaching because that DEFINITELY doesn't work with return carriages in the data.

Trust me, I tried it. It still gives the EOL error.

Does it work outside of ArcMap? Sure does. I call that limitations.

[IB1]

Jason, this does not work if the string has an embedded newline.

......

Thanks a lot for the helpful answer, I'll try it next time.

[Anonymous User]

The limitation you've run into isn't with Python but with the geoprocessing environment's inability to easily pass newlines around in arguments, even when escaped. (For example, in a Calculate Value code block you cannot include "\n" in your code, you need to use the chr() function to insert newlines in strings.)

Thank you for posting Curtis!!!!  I was struggling with this for a while...I did not think to use chr()...I was having issues passing newlines into advanced python label expressions and banging my head against the wall trying to figure out where I was going wrong.  This seems to be a nice workaround.