Are arcObjects in arcPro and Python 3.x at parity? What can't you do in Python 3.x?

1208
8
09-26-2018 12:19 PM
KeithOlsen
Occasional Contributor

I'm tasked with rewriting old vb arcObjects code for arcMap 10.3 -> arcPro 2.2. The tools interact with an SQL database. Is it possible to recreate the functionality in Python 3.x or should I stick with .NET for arcPro? I understand that arcObjects are more limited in arcPro and python more advanced, but are they at parity? What kinds of things can one NOT do in Python 3.x that one could do with .NET for arcPro? Thanks.

0 Kudos
8 Replies
DanPatterson_Retired
MVP Emeritus

perhaps if you gave a specific example it would help those that used net.

It isn't python 3 that is the real issue, it is whether there has been any significant changes in arcpy.  Python 3 is an improvement in many ways over python 2, but it is a different beast than arcobjects applications

KeithOlsen
Occasional Contributor

Thanks Dan. I'm just wondering if Python 3x has the ability to create forms and select features interactively like .NET does. I was curious if ESRI was planning on replacing arcObjects with Python altogether, but it sounds like that isn't the case at this point. I'm also wondering what features in .NET for arcPro are missing vs. .NET for arcMap. Do you know if there is a feature implementation document somewhere?

0 Kudos
DanPatterson_Retired
MVP Emeritus

esri hasn't implemented any python-based form creation that behaves nicely with ArcMap or for that matter, ArcGIS pro. 

I would hazard a guess that they probably won't although I would love to be proved wrong...

Nothing like dreaming about a QT-based, Dialog Designer replacement from the old ArcView 2/3 days

If you examine the arcpy folders in an ArcGIS Pro installation, you will quickly come to the realization that arcobjects won't be going away anytime soon.

I will leave the .NET people to comment, I have never had any use for its functionality in my workflow or applications

KeithOlsen
Occasional Contributor

Thanks Dan. Ah Avenue for ArcView. That was a fun period.

DuncanHornby
MVP Notable Contributor

I would say that if you are interacting with the application interface then .Net is what you need to be using. I have not had the opportunity to develop in Pro yet but when it first came out I had a look at it's development environment and one issue that is significantly different to ArcMap is that you have to develop in an asynchronous environment. I would strongly suggest you spend some quality time going through some of the Pro development course on the ESRI training site here.

DanPatterson_Retired
MVP Emeritus

One cool thing Duncan is the ability to interact with the map by inputting point, polyline or polygon shapes instead of specifying an pre-existing featureclass.

Say you want to do a near analysis of a point set to a couple of other points.  You can have a pre-existing featureclass as the first data set, then 'pencil' in the 'to' points in on the map.  It makes a temporary featureclass and runs the analysis

XanderBakker
Esri Esteemed Contributor

In addition to what Duncan Hornby and Dan Patterson have mentioned, I would like to explain a couple of things.

  • ArcObjects is not a part of ArcGIS Pro. ArcObject is COM, 32 bits and ArcGIS Pro is based on new 64 bit modern technology
  • The ArcObjects object model in ArcMap was a really fine grained object model. The object model used to built ArcGIS Pro and exposed through the SDK is less fine grained
  • To be able to decide to do .NET developement with the SDK of ArcGIS Pro or create a GP tool based no Python depends on the specific use case. 
  • A new feature introduced in ArcGIS Pro are tasks: What is a task?—ArcGIS Pro | ArcGIS Desktop which could help automate workflows.
  • What has been created based on ArcObjects will require a complete rewrite in ArcGIS Pro. Development of a GP tool based on Python and tasks will be a lot faster than the rewrite of the code in ArcGIS Pro.
  • On the other hand if the development include lots of form-based interaction, using .NET and the SDK will probably be the way to go.
StefanCoe
New Contributor II

What about enterprise geodatabase customization, such as arcobjects class extensions? I don't see how/where one would do this with ArcGISPro.