Scripting to Manipulate Data and Creating a Dictionary

We are cruising along now that we know Python fundamentals, this week creating a script that can manipulate data by creating a new geodatabase that contains copied data from a folder, and then creating and populating a dictionary using a for loop. The result of the script is below, there were several different elements working together to create a series of results. Watching this script function was very satisfying:

The biggest challenge for me, by far, was populating the dictionary using the for loop. I was completely lost on why I kept getting the “unhashable type: 'list' error”, or the literally printed "{'NAME' : 'POP_2000'}" without the proper values filling in.

I spent time searching UWF's references, searching online, and read through the student discussion forum. I would make an adjustment, and it would get a lot better… or way worse. And then, I realized my variables were not properly defined. This confused me, because it looked like I had defined them properly. After reading about others moving them, it suddenly started to make sense how I needed to better define them.

I started with (incorrect code seen below), but eventually started debugging my mistakes:

for row in cursor:

      row.getValue(key_field[0])

      row.getValue(val_field[0])

      count_seats.update

print(county_seats)

An odd thing I noticed while using Spyder, if I quit/restart Spyder’s terminal and run the script for the “first” time, it changes the results for the GetMessageCount(). I am not sure if that is intentional or not, but I was sure not to take my screen shots after a restart.

Not the first or last time I am sure to do this, but the first time I tried to run my script, the geodatabase was locked despite the <env.overwriteOutput = True> statement. It did not take long for me to realize I had ArcGIS Pro open, at which point I closed the program and it unlocked. I could imagine this to be a huge hindrance in some cases! Additionally, I feel like the error messages themselves are too confusing to be a huge help when debugging. Knowing where the bug is seems to be the best clue to why something is wrong, and if something is missing or just written badly, it can take some time to figure out why. 

Practice makes perfect, a couple more GIS Programming lessons to go!