topic Re: Migrating Python 2.7 From Desktop to 3.1 for Pro in ArcGIS Pro Questions

Migrating Python 2.7 From Desktop to 3.1 for Pro

Cartographer7 — Thu, 04 Jan 2024 03:25:34 GMT

We've been running ArcGIS Desktop with Python 2.7 and intend to migrate to ArcGIS Pro with Python 3.1 before the switchover in April:

1. Can Modelbuilder import Python scripts and make a model based on the scripts if they run successfully using the runtime of ArcGIS Desktop?

2. Can Python 2.7 scripts be migrated to ArcGIS Pro without editing, or are there syntax differences to be aware of?

3. Can MXDs with shapefiles be migrated easily from one platform to the next? Are there any significant syntax differences in the operands of each Arc platform?

Re: Migrating Python 2.7 From Desktop to 3.1 for Pro

DanPatterson — Thu, 04 Jan 2024 12:57:51 GMT

Some of your questions can be answered from this help topic and its sub-links

For ArcMap users migrating to ArcGIS Pro—ArcGIS Pro | Documentation

Re: Migrating Python 2.7 From Desktop to 3.1 for Pro

Bud — Thu, 04 Jan 2024 14:51:11 GMT

I'm not a Python person, but I dug up some info from an old email that might help you (we're moving from ArcMap 10.7.1 and ArcGIS Pro 2.6.8 —to— ArcGIS Pro 3x):

I found this article described the changes very well: https://pro.arcgis.com/en/pro-app/latest/arcpy/get-started/python-migration-for-arcgis-pro.htm
There’s actually a GP tool in ArcGIS Pro called “Analyze Tools for Pro” that can analyze your python scripts to see if they are Python 3/Pro compatible:
When we ran that tool against one of our scripts, the only issues it identified there were the “print” statements… they need to have brackets in Python 3.

Re: Migrating Python 2.7 From Desktop to 3.1 for Pro

Cartographer7 — Thu, 18 Jan 2024 02:58:43 GMT

Well that was certainly a start. I even got https://docs.python.org/3/library/2to3.html script to run.

But Analyze Tools for Pro stalls at 3%.

And looking at the output of running my revised script, SpatialJoin seems to call a script from the User home folder even though the original script is somewhere completely different, on a shared drive.

It calls a _base.py and an analysis.py, neither of which are in my original script. It did a SpatialJoin quite easily under ArcMap 10.8.2. So I need to know how to do a Spatial Join call in ArcPy Python 3.1?

Also based on the output has ArcGIS Pro removed DBF support in its python scripts?

Re: Migrating Python 2.7 From Desktop to 3.1 for Pro

DanPatterson — Thu, 18 Jan 2024 09:44:09 GMT

Every tool, under Parameters, has a Dialog and python tab

Spatial Join (Analysis)—ArcGIS Pro | Documentation

code examples are in the python tab

Re: Migrating Python 2.7 From Desktop to 3.1 for Pro

Cartographer7 — Sun, 21 Jan 2024 03:23:25 GMT

A few others thing that is sort of confusing is that the Python has an

https://pro.arcgis.com/en/pro-app/3.1/arcpy/get-started/setting-paths-to-data.htm

\\ versus \ standard

It seems when you do do an 'r' command you use a single slash.

When you just declare a path is what a variable is equal to, you use a \\

1. Is that correct?

2. I also noticed you can specify a path as the env.workspace, as your Windows path you are referring to.

but it appears that you can't use it as a tack on variable when doing a read.

so placeholdervariableforshapedotshp= r+env.workspace+"\shapefiles\shape.shp" won't work because the env.workspace is declared with \\

I had tried to create an renvworkspace = pathtoworkspace described with single slashes, and that doesn't appear to work either.

Can you tell me where I am assuming wrong?

Re: Migrating Python 2.7 From Desktop to 3.1 for Pro

DanPatterson — Sun, 21 Jan 2024 10:54:12 GMT

These work

c:\\temp\\poly.png c:/temp/poly.png r"c:\temp\poly.png" arcpy.env.workspace = r"c:\temp" image_file = "{}".format(arcpy.env.workspace) + r"\poly.png" image_file 'c:\\Temp\\poly.png' image_file = rf"{arcpy.env.workspace}" + r"\poly.png" image_file 'c:\\Temp\\poly.png'

1, 2 ... windows, "linux"

3 .... "raw" format

5,6, and 5,11 two variants of "f-string" formatting