topic Re: A script that used to work before is now behaving strangely. in Python Questions

A script that used to work before is now behaving strangely.

-_- — Wed, 23 Apr 2025 07:27:29 GMT

I was using a script to rewrite the graded color labels with Arcpy, but it stopped working (maybe after I updated to 3.4.3).
I simplified the code and tested it, and the labels were set for just a moment, but then they went back to normal.
Is there something wrong with this code?

import arcpy lyr="test" tani="ha" aprx=arcpy.mp.ArcGISProject("CURRENT") view=aprx.activeView mapname=view.map.name maps=aprx.listMaps(mapname)[0] l=maps.listLayers(lyr)[0] label_count_last=l.symbology.renderer.breakCount if hasattr(l.symbology, 'renderer'): if l.symbology.renderer.type == 'GraduatedColorsRenderer': sym = l.symbology sym.renderer.lowerBound = -10000000 #3.4 lowerBound set on Renderer for i in range(0,label_count_last): brk=sym.renderer.classBreaks[i].upperBound sym.renderer.classBreaks[i].label=str(brk)+tani sym.renderer.classBreaks[-1].upperBound = 10000000 #upperBound set on upper ClassBreak l.symbology = sym

When executed:

(view in My Videos)

Re: A script that used to work before is now behaving strangely.

DanPatterson — Mon, 21 Apr 2025 04:07:07 GMT

Do the classes stay in place is you drop the aprx.save()?

The code examples in the help use aprx.saveas or there is no saving.

Re: A script that used to work before is now behaving strangely.

-_- — Mon, 21 Apr 2025 07:24:11 GMT

Removing aprx.save() doesn't change the result.

Re: A script that used to work before is now behaving strangely.

DanPatterson — Mon, 21 Apr 2025 10:40:23 GMT

GraduatedColorsRenderer—ArcGIS Pro | Documentation

which leaves the lower bound statement

(Read and Write)
A double that represents the minimum value of the symbolized classificationField to be displayed.

Note:
The value of the lowerBound should only be set to a value within the range of the first class break, otherwise it will fail. The maximum value gets modified in the last class break by changing the upperBound property.

Re: A script that used to work before is now behaving strangely.

David_Lindsey — Mon, 21 Apr 2025 21:13:24 GMT

OP, what version of Pro did you upgrade from when you jumped to 3.4.3?

Re: A script that used to work before is now behaving strangely.

-_- — Tue, 22 Apr 2025 02:16:17 GMT

I think it was around 3.4.1.
However, when I upgraded to 3.4, various other problems occurred, so I can't clearly remember whether this problem was there at the time and I didn't notice it, or whether it started occurring when I upgraded to 3.4.3.

Re: A script that used to work before is now behaving strangely.

-_- — Tue, 22 Apr 2025 02:18:40 GMT

The original code included code to set upper and lower limits, but this has now been removed in order to identify the cause.

Does this code work as intended in your environment?

Re: A script that used to work before is now behaving strangely.

David_Lindsey — Tue, 22 Apr 2025 05:14:43 GMT

Unless this is you in the comment section of this Reddit post, you may not be the only one experiencing this issue recently. In my experience with minor releases (and given how much symbology-related stuff that Esri touched with the 3.4 release), I wouldn't rule out a bug being introduced. No mention of deprecations related to your issue in the release notes either. I use aprx.save() with my symbology updates as well, but haven't been doing the same workflows that you are doing. It does look like you are running the code while Pro is open though. Do the edits save correctly if you run the script as a standalone while Pro is closed? That test might help you rule out a lock or read-only issue...maybe. Oh, and be sure to save a copy of your project beforehand if you try anything as a standalone. I learned that lesson the hard way. Ha.

Re: A script that used to work before is now behaving strangely.

-_- — Wed, 23 Apr 2025 01:47:45 GMT

Sorry, I've always used the scripts in the toolbox and don't know how to run them standalone.

Re: A script that used to work before is now behaving strangely.

-_- — Thu, 24 Apr 2025 07:29:32 GMT

I still don't know why the original code was causing the problem, but I was able to use CIM access to rewrite the label.

import arcpy lyr="test" tani="ha" aprx=arcpy.mp.ArcGISProject("CURRENT") view=aprx.activeView mapname=view.map.name maps=aprx.listMaps(mapname)[0] l=maps.listLayers(lyr)[0] label_count_last=l.symbology.renderer.breakCount if hasattr(l.symbology, 'renderer'): if l.symbology.renderer.type == 'GraduatedColorsRenderer': l_cim=l.getDefinition('V3') l_cim.renderer.minimumBreak = -10000000 for i in range(0,label_count_last): brk=l_cim.renderer.breaks[i].upperBound l_cim.renderer.breaks[i].label=str(brk)+tani l_cim.renderer.breaks[-1].upperBound = 10000000 l.setDefinition(l_cim)

Re: A script that used to work before is now behaving strangely.

JeffBarrette — Thu, 24 Apr 2025 14:54:34 GMT

@-_- This is indeed a regression we discovered and fixed during 3.5 and will patch 3.4 with the next available patch. What happened was new behavior was added into the the software called "alwaysUpdateClassLabels". When you simply use the arcpy.mp API to update a class label, it got overwritten due to this new behavior.

aprx = arcpy.mp.ArcGISProject('CURRENT') active_map = aprx.activeMap lyr = active_map.listLayers()[0] sym = lyr.symbology sym.renderer.classBreaks[0].label = "Testing 123" #RESETS TO ORIG lyr.symbology = sym

But as you discovered, if the labels are modified via the CIM, it bypasses internal behavior and works.

aprx = arcpy.mp.ArcGISProject('CURRENT') active_map = aprx.activeMap lyr = active_map.listLayers()[0] lyr_cim = lyr.getDefinition('V3') lyr_cim.renderer.breaks[0].label = "Testing 123" #This works lyr.setDefinition(lyr_cim)

This applies to all renderers and colorizers with class breaks. Our apologies for the breaking change.

Jeff - arcpy.mp team

Re: A script that used to work before is now behaving strangely.

-_- — Fri, 25 Apr 2025 03:52:49 GMT

I see.
The latest version of the Japanese version I use is 3.4.3, so I didn't realize that there was a 3.5 version. I'm sorry.
I feel relieved now that I know the cause. Thank you.

Re: A script that used to work before is now behaving strangely.

JeffBarrette — Fri, 25 Apr 2025 13:57:44 GMT

@-_- Pro 3.5 is soon to be released but we will also patch Pro 3.4. The next patch will be Pro 3.4.4.

Jeff - arcpy.mp team