Tuesday, May 14, 2024

Lab 1: Python Environments & Flowcharts

PEP 20 - The Zen of Python

Having read "The Zen of Python" in the past, it is something I have always found joyful, frustrating, and ironic given other languages or development philosophies. Below is my synopsis of these nineteen guiding Python design principles.
First, "Beautiful is better than ugly." Given the suite of other high-level interpreted programming languages, Python's syntax is rather ugly. Its usage of space to delineate code blocks is just frustrating and awkward. Yet its syntax is not as ugly as other interpreted languages like Perl or Bash.
"Explicit is better than implicit." has some merits but also some faults when comparing the Ruby on Rails mantra, "Convention over configuration." To limit software to strict explicit definition and not permit logical defaults through established conventions will generate a buggy, high-maintenance application.
The next two principles are symbiotic, "Simple is better than complex." and "Complex is better than complicated." are somewhat subjective. For the sake of brevity, let us add the seventh principle, "Readability counts." to this group since readability is largely based on experience and skill. Authoring concise, optimized code at times may appear complex to novice programmers but with experience, it is anything but. As for myself, the two should be summed up as, "Get to the point and leverage as much of the information already in memory as possible," or simply, "Stop mucking about and creating an unnecessarily large memory footprint."

This next group of principles holds true regardless of the language: "Flat is better than nested.", "Sparse is better than dense.", "If the implementation is hard to explain, it's a bad idea.", and "If the implementation is easy to explain, it may be a good idea." The cognitive load necessary to understand a 50-line nested if-else statement is largely beyond even the best evil genius. Sparse code is somewhat subjective; as programming skills increase, a single line of dense code is effective and easy to understand. The last two in this group are basically the same as the programming jargon "rubber ducking," meaning that if you are unable to explain the problem in plain language, it's probably unnecessarily complex. The rubber duck aspect is from the book "The Pragmatic Programmer," where the author would explain code line-by-line to a rubber duck.

The next group of principles holds true regardless of the language: "Flat is better than nested," "Sparse is better than dense," "If the implementation is hard to explain, it's a bad idea," and "If the implementation is easy to explain, it may be a good idea." The cognitive load necessary to understand a 50-line nested if-else statement is largely beyond even the best evil genius. Sparse code is somewhat subjective; as programming skills increase, a single line of dense code is effective and easy to understand. The last two in this group are basically the same as the programming jargon of rubber ducking, meaning that if you are unable to explain the problem in plain language, it's probably unnecessarily complex. The rubber duck aspect comes from the book "The Pragmatic Programmer," where the author would explain code line-by-line to a rubber duck.

Those remaining which not so much coding or software design principles but practical, task-oriented methodologies to aid in getting things done or, better yet, prevent one from overthinking the design.

Python Environments - IDLE & ArcGIS Notebook

IDLE (Integrated Development Environment) is a basic shell and editor that is included with Python. It is a standalone application which is great for general purposes, quick prototyping, or one-off scripts. Its basic read-eval-print loop (REPL) is simple to use and understand but lacks a number of features more advanced users may seek.

As for ArcGIS Notebook, it is a vendor-specific spin of Jupyter Notebook, which is a web-based interactive development environment. Being part of the ArcGIS ecosystem, it is geared towards geospatial analysis and visualization. Unlike a line-by-line interaction like IDLE, ArcGIS Notebook utilizes cells which contain either code, data, markdown, or visuals, evaluated in a top-down manner. Yet, they are both development environments for Python which allow users to interactively author and execute code and display results.

Running the Python Script

One would think that they could press the Windows key, type "IDLE," and open the application. But in true Windows fashion, that expectation is a bust since it opens an IDLE for Python 2, not Python 3. I can only assume this is because ArcDesktop (ArcMap) is also installed, and to the best of my knowledge, it still utilizes Python 3. Looking over the CreateModFolders.py, it states that it was authored for the oddly precise version 3.6.5, so one can only conclude that running it using the installed IDLE, which leverages version 2.7.18.4, could fail or have an unexpected outcome.

To run the script, it was as simple as opening a terminal and passing the file as an argument to the Python interpreter. As to why a utility script like this does not contain a shebang is a mystery. Once executed, a quick look and voilĂ , the expected directory structure is created.

Flowchart

Software for creating flowcharts and Unified Modeling Language (UML) has come a long way. There are tons of freely available online tools like Visio, but my go-to tool is still the age-old Dia. It may not produce the most fancy-looking diagrams, but it is a great all-around tool, especially for class, entity-relationship (ER), and sequence diagrams. Embedded is the diagram for the radians to degrees formula, assuming that the Python math.pi constant exists.

No comments: