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 set. 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
Running the Python Script
Flowchart
math.pi constant exists.
