Pro corrupts my python label expressions when using a table join.

[Matt-Goodman]

I'm using python label expressions to label address points. They concatenate various address element fields using python's .join() function. 

If I apply an attribute join to my address point feature class (in an enterprise geodatabase) my python label expressions are altered by the program and they no longer work.

Here is the python label expression before applying the join (works great like this):

' '.join(str(i) for i in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF]) if i)

Here is the same expression after applying the join, Pro has altered it (the syntax is bad / does not work):

' sde.SL.address.'.josde.SL.address.IN(str(i) sde.SL.address.for i sde.SL.address.IN ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF]) sde.SL.address.if i)

In the above, you can see that it mishandled the original python expression. It did not handle the opening parenthesis correctly and it upper-cased all instances of python 'in' to (SQL?) 'IN', even in the word 'joIN'. Also, I don't know why the letters 'jo' were appended to 'sde', which is the database instance. 

Finally, here is the same python expression after I have removed the table join and the program has tried (unsuccessfully) to revert it back to its original syntax:

' '.joIN(str(i) for i IN ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF]) if i)

Notice the two instances of capitalized 'IN'. Python doesn't like these.

I'm thinking this should be logged as a bug that needs to get fixed? 
 

[Matt-Goodman]

Has anyone else experienced this issue?

[RhettZufelt]

I tested in 2.9.3 and can confirm that it is messing things up, though slightly different than yours.

I don't get any captialization of the "in(s)", and when I remove the join, nothing changes.  It keeps the mucked up code.

Original code (works):

' '.join(str(i) for i in ([DirectPrefix],[StreetName],[DirectSuffix]) if i)

After add join (broken):

' PublicWorksApps.DBO.teststreets.'.joPublicWorksApps.DBO.teststreets.in(str(i) PublicWorksApps.DBO.teststreets.for i PublicWorksApps.DBO.teststreets.in ([DirectPrefix],[StreetName],[DirectSuffix]) PublicWorksApps.DBO.teststreets.if i)

After remove join (still broken):

' PublicWorksApps.DBO.teststreets.'.joPublicWorksApps.DBO.teststreets.in(str(i) PublicWorksApps.DBO.teststreets.for i PublicWorksApps.DBO.teststreets.in ([DirectPrefix],[StreetName],[DirectSuffix]) PublicWorksApps.DBO.teststreets.if i)

R_

[Matt-Goodman]

Thanks for testing this in 2.9.3!
FYI: I forgot to mention I'm using 3.0.0.

[RhettZufelt]

I have noticed that if I put the join on before the label expression, it works as expected.

R_

[Matt-Goodman]

FYI: I tested this using data from a file geodatabase and some of the behavior was similar, but overall it worked slightly better. The software did corrupt the Python syntax while the join was on, but after the join was removed, it was correctly reverted back to a working expression. The program did not uppercase the word 'in', and it did successfully revert the expression back to valid Python syntax after the join was removed, but while the join was on, the syntax was bad. 

Label expression before the join (labels work as expected):

' '.join(str(i) for i in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF], [LST_PREDIR], [LST_NAME], [LST_POSTYP], [LST_POSDIR]) if i)

Label expression during the join (labels do not work, bad Python syntax): 

' adp.'.joadp.in(str(i) adp.for i adp.in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF], [LST_PREDIR], [LST_NAME], [LST_POSTYP], [LST_POSDIR]) adp.if i)

Label expression after the join (labels work again, as expected): 

' '.join(str(i) for i in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF], [LST_PREDIR], [LST_NAME], [LST_POSTYP], [LST_POSDIR]) if i)

[Matt-Goodman · Accepted solution]

I reported this to Esri and they were able to reproduce the issue and logged it as a bug: BUG-000151759

[AngelBarnett]

I'm still having this issue in 3.2.1