I have been working with Django, specifically GeoDjango, on and off for a few weeks, and I must say it has opened my eyes. When working with the GeoDjango GEOS API, geometries work quite a bit different than in ArcGIS.
GEOSGeometry objects are ‘Pythonic’, in other words components may be accessed, modified, and iterated over using standard Python conventions.
Since the idea is already implemented and documented, I won't dive into the specifics here of how true or more Pythonic geometries work. Given that ArcPy is a Python site package, I think ArcPy geometries should be a bit more robust in terms of using standard Python conventions to interact with them. This is one area where ArcGIS Pro has been a big let down, i.e., ArcGIS Pro was not used as an opportunity to re-invent/re-invigorate the ArcPy site package.
I have posted the idea on ArcGIS Ideas (Pythonic ArcPy Geometries) and opened an Esri Support Enhancement Request (ENH-000089037: Make ArcPy Geometries truly Pythonic) if anyone wants to vote for it or attach their customer number to the idea.
you should be able to create both. The island version if easily doable but the multipart by attribute is another story. Xander pointed that out to me in a thread (which I can't track down now), that you can make valid multipart polygons if they share no more than a single point but if they share one line then the intervening line gets removed and adjacent polygons get combined EVEN if their Z or M values differ. Picture a series of squares in a row, with increasing Z values but each sharing a common line (or two), there is no way to make that a multipolygon because arcpy and its underlying code only uses X and Y in tests for equality. Also...try to make a vertical polygon for display in 3D...you can't and I have to rely on other software for display. And forget getting distracted and trying to construct a tessaract...Tesseract - Wikipedia, the free encyclopedia
I would have hoped that with the push to 3D that the geometry engine be improved, but I have seen no reference that the new Pro offers much in that...It must lie in City Engine, but I have had no time to check
Rumor has it that Geometry indexing and slicing is coming at ArcGIS 10.4.1. I am still trying to track down specifics, but what I have heard so far is at least a glimmer of hope.
This is what's mentioned on the What's new (in ArcMap ) page:
ArcGIS 10.4 has been upgraded to include Python 2.7.10. Additional third-party libraries including SciPy, pandas, Sympy, and nose have been included, and existing third-party libraries including NumPy and matplotlib have been upgraded to more current releases.
The GetPackageInfo function has been added to return a dictionary about packages.
I'm struggling here at the client site to update the license manager to 10.4, but I have to file a change request and a lot of related stuff... for 5 minutes work... so no way I can test to see if there is more news on the geometries...
Good... some progress... but I can't figure out why they didn't upgrade to at least 3.4.* since ArGIS Pro uses it. So all the SciPy stack modules are for 2.7.10 I presume. I have happily been using the 3.4.* stack for a while, the differences between numpy 1.8 and 1.9 (or 1.10) are subtle, but there have been a few changes that are worth it... I will post more on the diffrence in the Numpy Repository when I get some time.
It would be great if Esri gave an indication of when, or if, they will move ArcGIS for Desktop (or is it ArcMap) to Python 3.x. The deeper I get into my transition to 3.x, the more little things pile up that are annoyances going back to 2.7.x.
From what I have heard, the geometry changes are still baking, didn't quite rise in time for the 10.4.0 release.
I hope indexing and slicing bake enough for the 10.4.1 release. I would like to see indexing and slicing return other geometry objects, but I get the impression they will return ArcPy arrays much like getPart.