Select to view content in your preferred language

Calculating "None" Using Field Calculator Yields "WARNING 003571"

3472
9
Jump to solution
11-16-2022 04:55 PM
VinceE
by
Frequent Contributor

Experienced this in ArcGIS Pro 3.0.2. Couldn't replicate in 2.9.

I was recently setting some values to NULL using Field Calculator. Expression type is Python 3, value I am inputting is None. To be clear, I'm typing in None without quotes or anything extra. Just the Python data type None. This used to set all values in the field to Esri's NULL, represented as <Null>. Standard stuff.

However now this operation yields the following:

[WARNING 003571: Certain rows set to NULL due to error while evaluating python expression: Cannot be evaluated to value.]

To be clear, the operation still works--highlighted rows in the specified field (tested with SHORT and TEXT fields) still evaluate to NULL. I'm just curious what the function of this warning is. Is there now a preferred way of setting values to NULL? If this Python expression results in an evaluation "error," as stated in the warning  message, why does it still work? Is there something that has changed here that I should be aware of? Am I missing something?

Thanks in advance if anyone has any insight into this bizarre change.

1 Solution

Accepted Solutions
Robert_LeClair
Esri Notable Contributor

Vince - from what I've learned in the internals:

Resolution:

- Reached out to our internal team and it was confirmed that Warning: 003571 is an expression validation that was added at 3.0 as the datatype being calculated and the datatype of the field is different. Although it does not affect the output that you get, still ArcGIS Pro 3.0 would produce this warning.
- None is NoneType and not String which makes sense for a Text field. The same warning appears if you try applying a tuple to a string field. See our internal note on this below: "The expression can be valid python code, say "3,2" (a tuple two integers) but not be a valid value for the target field. Historically this would result in a Null value getting PUT into the row. At Pro 3.0 this is still the case however we produce a warning."

Hope this helps!

View solution in original post

9 Replies
DanPatterson
MVP Esteemed Contributor

003571: Certain rows set to NULL due to error while evaluating Python expression: Cannot be evaluate...

And yes it does set things to null (my field in the image had numeric data in it as well as <null>

setnull.png

Now, numpy and math have "nan" (not a number, aka None-ish)

setnull1.png

with no warning and it sets to <null>

setnull2.png


... sort of retired...
0 Kudos
VinceE
by
Frequent Contributor

Thanks anyway Dan, but I am familiar with the error number--it's in my original question. I am also aware that using "None" (without the quotes) still works. Again, that is in my original question. I am not clear on your point regarding "math.nan".

I would like to understand why this warning message has been added, or what is happening under the hood. What am I even being warned of here? Seems to me, Python's None data type has been the universal "<Null>-setter" for quite some time: numeric fields, text, fields, date fields, etc.

Robert_LeClair
Esri Notable Contributor

Vince - from what I've learned in the internals:

Resolution:

- Reached out to our internal team and it was confirmed that Warning: 003571 is an expression validation that was added at 3.0 as the datatype being calculated and the datatype of the field is different. Although it does not affect the output that you get, still ArcGIS Pro 3.0 would produce this warning.
- None is NoneType and not String which makes sense for a Text field. The same warning appears if you try applying a tuple to a string field. See our internal note on this below: "The expression can be valid python code, say "3,2" (a tuple two integers) but not be a valid value for the target field. Historically this would result in a Null value getting PUT into the row. At Pro 3.0 this is still the case however we produce a warning."

Hope this helps!

VinceE
by
Frequent Contributor

Robert, I appreciate the clarification on when and why this was added. Very helpful, thanks!

anonymous_geographer
Frequent Contributor

Hey Robert, thanks for clarifying. I know this is an older message I'm responding to and that you are merely a messenger, but I wanted to say that I hope your internal team reviews this Warning message configuration. The reason I say that is summed up in one word: Inconsistency.

If I do an Arcade expression with null, there is no Warning message. If I do a VBScript expression with NULL, there is no Warning message. Why is there a Warning message exclusive to Python expressions for nulling the field? Also, nulling a Python string is not an error when coding in, well, any IDE I've ever used. An absence of a string value has never been a problem (so long as the field is nullable).

The warning message is even more convoluted because it uses the wording "error" with a Warning message's explanation. Esri has Error messages and Warning messages. Error wording should not exist in a Warning message. This is causing our end-users a lot of confusion and, our support staff, wasted headaches because we have to try and explain to them the Esri thought-process here (I rate my answers a D- so far..).

Best case solution: Nulling a nullable field should be excluded from this scenario....because it's a legal operation.
Worse case solution: the Warning message should be updated where "error in evaluating Python expression" is removed/reworded for null scenarios.

Okay, I'm off my soapbox now!

- A GIS programmer

Robert_LeClair
Esri Notable Contributor

Hey anonymous_geographer!  Yes, I'm just the messenger from Esri Training Services and, unfortunately, do not work for the ArcGIS Pro Development Team.  I wonder if @KoryKramer has any insight of the Arcade vs. VBScript vs. Python messages?

0 Kudos
anonymous_geographer
Frequent Contributor

Thanks for pointing that out, Bud. Take my upvote!

Charles_Song
New Contributor

I agree. This warning is very unnecessary. I hate to have an extra click every time I use calculator to set value to None -- which I do 100 times a day.