nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Field Calculator '.cal' file encoding ... not '.py'

DanPatterson_Retired

The ability to save and reuse python snippets for using in the Calculate Field tools is useful (aka... the field calculator for non-ArcGIS Pro users). A couple of questions then...

UTF-16-LE .... the encoding used for some reason rather than utf-8 for instance
UC2-2 LE BOM ... is this good enough if you use a Notepad++ file?
-*- coding: <encoding-name> -*- as the first line using either the UTF or UC2 version... will that solve encoding problems with the *.cal files?

And the biggie....Why can't you use Python *.py files?

It is more out of curiosity and... I have to teach... so this is what I have to tell my students...

the default language used in Pro is Python...
Python files have a *.py file extension ...
except in the calculate field tool for Pro,
*.cal files is all you will see,
save your 'defs' as cal and py files if you want to use them everywhere
no more questions now... I have a headache

Some illumination would be useful so I can expand my bullet list. Others that teach out there, may wish to jump in with addition missives should they have encountered any

Curtis Price‌ Timothy Hales‌ perhaps, or an FYI##

Najděte více příspěvků označených jako

Accepted answers

All comments

JoshuaBixby

Great question Dan. I would like, or even hope, someone knowledgeable from Esri responds but we will have to wait and see.

I foresee a "compatibility" argument being made, which will be frustrating because I think Esri talks out both side of their mouth when it comes to compatibility between ArcMap and ArcGIS Pro. I ran into an issue the other day where the parameter order of an ArcPy function changed between ArcMap and Pro, and the argument was made that Pro is a new application not everyone will work example the same. Yet, somehow the CAL file survived.

forestknutsen1_0-1662769886289.png

DanPatterson_Retired

Thanks Joshua... as for the parameter out of order issue... while we wait... I use the named parameter method generally rather than relying on position of the parameter... makes the code a bit longer to write the first time, but is manageable should someone pull a fast shifty on us.

Lets pull in some of the others... to add to the list since they might have an insider perspective or could raise this issue during the plenary session coming up at UC

xander_bakker‌ vangelo-esristaff‌ jayanta.poddar‌

curtvprice

the parameter order of an ArcPy function changed

Please do tell which function! I have found this pretty unusual - I have a pretty complex toolbox written in 9.3 that still works.

DanPatterson_Retired

quit getting off track .... focus on the main question and we might tell you

EDIT

PS... I have a short list of 10+ in the evolution of Pro since 1. to 1.4.1... and that doesn't include enhancements but additions/changes to the tool parameters. I have counted groups of changes as 1 since there a bunch of changes in a category of tools that affected all tools within it.

But I digress from the pressing issue

mody_buchbinder

Hi Dan

This is a good question and I had these problems too.

My workaround is to replace the calc tool with simple python script that run an update cursor. Then I can run a "real" python script. The update cursor itself is just a few lines around the calc expression.

Mody

DanPatterson_Retired

Fresh ones arrive... with 10.5.1 more parameters in slope and aspect check geoprocessing section and Pro 2.0 is live

curtvprice

The help for 10.5.1 and Pro 2.0 is up, but no software yet for me on my.esri. Probably very soon though.

This is cool: GPU processing with Spatial Analyst—Help | ArcGIS Desktop

DanPatterson_Retired

Wow... 29 viewers, hi to the esri staff that I haven't heard of. 325 emails? must have generated some interest.

BUT

I will close this off as a discussion since it appears that the status quo will remain for some reason (legacy purposes?).

Workarounds abound ... I don't need them, but thank you. I am more interested in finding a suitable explanations for my students without using

'.... because, that's the way it is... '

in an explanation of why python is widely adopted, except when saving in the field calculator.

Anyone at UC... ask around...

Dan

ScottDrzyzga

Thanks for posting this, for you helped me answer an unrelated question. I had a student that used a text editor to edit a *.cal file, but on [Load], all the characters had "changed" to Chinese. We kept trying to fix it by saving to UTF-8 or ANSI, but ... UC2-2 LE BOM. Thanks.

While I'm here, has the big question been answered yet? Not here, obviously, but elsewhere?

"And the biggie....Why can't you use Python *.py files?"

HodaEL_2-1662816407569.png

DanPatterson_Retired

It hasn't.... and there is probably some reason beyond 'inertia', that I am not privy to.

In any event, I just keep two exact same versions, or if I just forget, I change the file extension and comment out the last 2 lines that the *cal version magically adds

__esri_field_calculator_splitter__
angle_between(!Shape!, True)

Those two lines are what populates the Expression box so that the *cal does all the work for you.

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.