Is there a way to use python get the geometries of the feature classes in sde?

[RPGIS]

Hi,

So I am working on a script to automate a process for populating certain fields in several feature classes, but in order to do so I need to determine what kind of geometries these feature classes are. Depending on what kind of feature classes they are, the script runs a certain way. The issue I am having with the script is I am not getting the list of geometries for the feature classes. The feature classes are in sde (not sure if that makes a difference) and I keep getting a list, but not a list of the geometries. Any help would be greatly appreciated.

import arcpy

arcpy.env.workspace = r'Database Connections\Storm Water.sde\STORM.GISADMIN.Storm_Network'

fcs = []
descList = []
fclist = arcpy.ListFeatureClasses()
for fc in fclist:
    fcs.append(fc)
for fc in fcs:
    desc = arcpy.Describe(fc)
    descList.append(desc)‍‍‍‍‍‍‍‍‍‍‍‍

[DanPatterson_Retired]

Yours is much clearer and easier to dissect should something should go wrong.... compare to

a more compact version and you will see

for fc in fcs:
    shp_type = arcpy.Describe(fc).shapeType
    name = os.path.splitext(os.path.basename(fc))[1].lstrip('.')
    print '{} is a {}'.format(name, shp_type)

# ---- or.... for python 3.6 +
for fc in fcs:
    shp_type = arcpy.Describe(fc).shapeType
    name = os.path.splitext(os.path.basename(fc))[1].lstrip('.')
    print(f'{name} is a {shp_type}')‍‍‍‍‍‍‍‍‍‍

[RPGIS]

Thanks Dan,

I never really thought about that. I simply thought a script that is written with fewer lines looks aesthetically better, but never considered troubleshooting as a factor in writing the script. I am relatively new to this and I see people write these in so many ways, but they oddly function the same.

So the thing that I am unsure about is if there is a particular method to writing scripts, or is that simply dependent on personal preference.

Robert

[JoshuaBixby]

a script that is written with fewer lines looks aesthetically better

I think readability is a bit more objective of a measure than aesthetics.  At some point streamlining or reducing lines of code becomes code golf, fun to play but seldom the best approach for portability, maintenance, etc....

[RPGIS]

Yeah I wasn't sure the best way to put it. At what point does reducing the lines of code become constraining. I don't code a whole lot but I think knowing the do's and don'ts for reducing lines of code may definitely help.

So when is it best to reduce lines of code and when is it not. I would like to know just in case so I don't make the mistake or doing it too much to where troubleshooting the script may turn into a hassle.

[JoshuaBixby]

Unfortunately Robert, there is no hard fast rule.  As Micah pointed out in an earlier response, what seems natural in terms of compactness might seem too dense for someone else.  For me, personally, I have learned over time by setting code aside and revisiting it a while later.  If I read code that I wrote a few weeks or months ago, and I need to really pause and think hard about what a line or loop is doing, then I likely went too far in condensing the code.

Honestly, for now, I wouldn't worry to much about writing compact and/or beautiful code, just focus on learning the language, especially being idiomatic.  For me the ugliest Python code is code structure that people bring over from their understanding of other languages but don't bother to rewrite it to be "Pythonic."  Several good examples are shown in Ned Batchelder's 2013 PyCon presentation:  Ned Batchelder: Loop Like A Native 

For example, someone might take a C or JavaScript approach to looping over a list:

for i in range(len(my_list)):

    v = my_list

    print(v)

while it can be done much simpler in Python:

for v in my_list:

    print(v)

[RPGIS]

Thanks Joshua,

I was just curious since I wasn't sure if there was a particular way in which code is written. I am slowly getting the hang of it and so far the scripts are working, but the direction might need some more clarity. I talked with one of my coworkers who suggested to create a diagram of what you would like to accomplish, and from that diagram write the code that corresponds with each step in the diagram. That has worked for me so far, but I also noticed that ( due to the limited experience with python ) I tend to lengthen my coding a bit. The code works but in some areas I would like to figure out where I can simplify the structuring just a bit, especially if the code is designed to accomplish something simple.

[JoshuaBixby]

If you have specific code snippets that you think can be simplified, I am sure the GeoNet community can share some thoughts.

[MicahBabinski]

I really love where this thread has gone, especially since we all have to read code as well as write code. From my conversations with other professionals, a lot of people start out their GIS Python scripting journey by reading and modifying existing code to fix bugs, change variables, add tools, etc. Personally, I took a class in 2012 and more or less dove in. I made lots of mistakes along the way, and continue to do so! Referring to the example I gave to Robert:

fc.split(".")[-1]‍

is something I have typed many, many times, so placing it inside the format function makes sense to me. But Dan's example is indeed more readable.

Anyways, folks might find this resource useful: Style Guide for Python Code by Guido van Rossum et al. Lots of good practical guidelines as well as philosophy. I googled 'Python Best Practices' after checking this thread this morning so I am going to check it out myself.