Module 3: Debugging

This module was much more straightforward than the prior. I am sure part of this is just the extra practice and increased understanding that goes with working through problems. I am glad that this module has been moved to earlier in the class so that we can find our problems in a systematic way.

During this module, we learned several ways to work through exceptions: Visual inspection of syntax, print statements, commenting out a line of code (or lines), and using the debugger tool in Spyder. I used all the tools throughout the exercise and assignment. Besides the visual inspection, I probably commented out several times to work through different versions of the script.

For Part 1, I just had to find two errors in the script. This was very easy, as this was just the warm up for the next two parts. When looking at syntax errors, the key is to consider indenting script properly and consistently, ensuring correct use of upper/lower case, symbols placement ("", :, etc.), and spelling.

Module 3, Part 1, Script 1

The above output was the result of correcting two script errors, which returned the feature classes in a geodatabase. A key to the exercise was ensuring that the scripts provided were in the correct location by verifying in ArcGIS Pro.

For Part 2, there were eight errors. These errors built onto the prior errors, but still contained many syntax errors. There was only one error that was a little difficult to find; however the debugger tool came in handy along with commenting out (using a #) and trying new lines of script. Once the script ran correctly, it printed out the names of the layers in the project's map.

Module 3, Part 2, Script 2

I was a little worried about Part 3 because it was the final step and I knew it would be the culmination of the entire module. For Part 3, we were expected to find an error, which was easy with the debugger tool. We were not supposed to fix the error, but use the try-except statement so that the script would execute with an easy to read statement and then continue to Part B. If correct, Part B would execute without error. The try-except statement was easy; however, it is imperative that you check your indenting so that those actions still remain within the script instead of outside. Below is the flowchart created to assist with this part.

Module 3, Part 3, Script 3

As you can see above, Part A ran, but returned an error statement that I had added to the code with my try-except statement. Once this executed, Part B ran and returned the names of the feature classes, data source, and spatial reference.

All my lessons learned are presented throughout this posting. A lot of this is just attention to detail. A big lesson learned for me was that everyone has errors and that many of the errors are simple spelling or punctuation mistakes. Look at those issues before deep-diving into the actual code. Additionally, the debugger tool is of great assistance.

Module 2: Python Fundamentals

For this week's exercise and assignment, there were numerous operations broken down into four steps. These steps included creating a string variable, creating a list, creating loops and iterating variables, and removing specific variables.

In Step 1, I created a string of my full name,  split the string to separate my individual names, and then used the index function to return a specific name. It is important to note that one uses 0 to return the first name and -1 to return the last portion of a string.

Step 2 required me to determine errors in a random dice game. This required me to first import the random module, which is the first line of code. I then looked at the script provided in the assignment to find two errors. A few things to note in errors: Ensure your quotation marks are not confused with contractions as it will confuse the program and return an error, make sure the case (upper/lower) is consistent, especially when naming a variable, and watch indention.

Step 3 caused me quite a bit of problems, as I overthought everything. In this scenario, I had to create a loop using a while statement and then append numbers to it until I reached 20 separate numbers. Again, this script required me to import the random module as the first step. One lesson I learned is that if you want to break the loop, the break must have the same indention as the loop. Otherwise, Python will return an error. I also learned that there are many different ways to arrive at a break statement.

For Step 4, I used the numbers generated in Step 3 (or I could have added this script to the script in Step 3). I then chose an integer as an unlucky number, used the while loop to remove the unlucky number, and then created a new list. This was fairly straightforward and of no issue. However, the next logical step in the future could be to remove the unlucky number and replace it so that there were still 20 numbers in the list.

Below are the results of my script, which has the return of each script. The explanations are written above, so I will not repeat them.

Script for Module 2. This shows the return items for each step in the assignment as explained above.

Flow Chart for Step 4.