-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
308 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,304 @@ | ||
--- | ||
title: The Zen Explained | ||
description: Aphorisms that capture the philosophy of Python | ||
authors: mkeithx | ||
date: 2025-03-01 | ||
slug: /updates/import-this | ||
# image: ./img/valentines-2025.png | ||
tags: [user_story, facts] | ||
--- | ||
|
||
**Embracing Python's Philosophy** | ||
|
||
The Zen of Python, written by [Tim Peters](https://en.wikipedia.org/wiki/Tim_Peters_(software_engineer)), is a collection of aphorisms that guide Python developers in writing clean, readable, and maintainable code. | ||
|
||
{/* truncate */} | ||
|
||
## `import this` | ||
|
||
<!-- The Zen of Python, written by [Tim Peters](https://en.wikipedia.org/wiki/Tim_Peters_(software_engineer)), is a collection of guiding principles for writing computer programs in the Python language. These aphorisms capture the philosophy of Python and help developers write clean, readable, and maintainable code. Let's explore each aphorism, its meaning, and provide examples: --> | ||
|
||
### **_Beautiful is better than ugly_** | ||
Clean, readable code is easier to understand and maintain. | ||
|
||
* **Beauty** | ||
```python | ||
def calculate_area(radius): | ||
return 3.14 * radius ** 2 | ||
``` | ||
* **Ugly** | ||
```python | ||
def calcArea(r): | ||
return 3.14*r*r | ||
``` | ||
|
||
### **_Explicit is better than implicit_** | ||
Clear and straightforward code is preferable. Avoid hidden meanings and ensure that the purpose of the code is obvious. | ||
|
||
* **Explicit** | ||
```python | ||
import datetime | ||
current_date = datetime.datetime.now() | ||
``` | ||
* **Implicit** | ||
```python | ||
from datetime import * | ||
current_date = now() | ||
``` | ||
|
||
### **_Simple is better than complex_** | ||
Simplicity leads to better code. Complex solutions should only be used when absolutely necessary. | ||
|
||
* **Simple** | ||
```python | ||
def add(a, b): | ||
return a + b | ||
``` | ||
* **Complex** | ||
```python | ||
def add(a, b): | ||
result = 0 | ||
for i in range(a): | ||
result += 1 | ||
for i in range(b): | ||
result += 1 | ||
return result | ||
``` | ||
|
||
### **_Complex is better than complicated_** | ||
If complexity is unavoidable, it should be well-structured and understandable, not convoluted or confusing. | ||
|
||
* **Complex** | ||
```python | ||
def factorial(n): | ||
if n == 0: | ||
return 1 | ||
else: | ||
return n * factorial(n-1) | ||
``` | ||
* **Complicated** | ||
```python | ||
def fact(n): | ||
return 1 if n == 0 else n * fact(n-1) | ||
``` | ||
|
||
### **_Flat is better than nested_** | ||
Avoid deep nesting of code structures. Flat code is easier to read and manage. | ||
|
||
* **Flat** | ||
```python | ||
if condition1: | ||
do_something() | ||
elif condition2: | ||
do_something_else() | ||
``` | ||
* **Nested** | ||
```python | ||
if condition1: | ||
if condition2: | ||
do_something() | ||
else: | ||
do_something_else() | ||
``` | ||
|
||
### **_Sparse is better than dense_** | ||
Spread out code with appropriate spacing. Dense code can be hard to read and understand. | ||
|
||
* **Sparse** | ||
```python | ||
def greet(name): | ||
print(f"Hello, {name}!") | ||
``` | ||
* **Dense** | ||
```python | ||
def greet(name):print(f"Hello, {name}!") | ||
``` | ||
|
||
### **_Readability counts_** | ||
Code is read more often than it is written. Prioritize readability to make it easier for others (and yourself) to understand and maintain. | ||
|
||
* **Readable** | ||
```python | ||
def calculate_sum(numbers): | ||
total = 0 | ||
for number in numbers: | ||
total += number | ||
return total | ||
``` | ||
* **Less Readable** | ||
```python | ||
def calc_sum(nums): | ||
return sum(nums) | ||
``` | ||
|
||
### **_Special cases aren't special enough to break the rules_** | ||
Stick to the rules and conventions of the language, even for special cases. Consistency is key. | ||
|
||
* **Following the rules** | ||
```python | ||
def divide(a, b): | ||
if b == 0: | ||
raise ValueError("Cannot divide by zero") | ||
return a / b | ||
``` | ||
* **Breaking the rules** | ||
```python | ||
def divide(a, b): | ||
if b == 0: | ||
return None | ||
return a / b | ||
``` | ||
|
||
### **_Although practicality beats purity_** | ||
While following best practices is important, practical solutions should take precedence when necessary. | ||
|
||
* **Practical** | ||
```python | ||
def read_file(file_path): | ||
try: | ||
with open(file_path, 'r') as file: | ||
return file.read() | ||
except FileNotFoundError: | ||
return "File not found" | ||
``` | ||
* **Pure** | ||
```python | ||
def read_file(file_path): | ||
with open(file_path, 'r') as file: | ||
return file.read() | ||
``` | ||
|
||
### **_Errors should never pass silently_** | ||
Errors should be handled properly. Ignoring errors can lead to unexpected behavior and bugs. | ||
|
||
* **Handling errors** | ||
```python | ||
try: | ||
result = 10 / 0 | ||
except ZeroDivisionError as e: | ||
print(f"Error: {e}") | ||
``` | ||
* **Silently passing errors** | ||
```python | ||
try: | ||
result = 10 / 0 | ||
except ZeroDivisionError: | ||
pass | ||
``` | ||
### **_Unless explicitly silenced_** | ||
If an error must be ignored, it should be done explicitly and with good reason. | ||
* **Explicitly silencing errors** | ||
```python | ||
try: | ||
result = 10 / 0 | ||
except ZeroDivisionError: | ||
result = None # Explicitly handling the error | ||
``` | ||
### **_In the face of ambiguity, refuse the temptation to guess_** | ||
When code behavior is unclear, do not make assumptions. Seek clarity and ensure the code's intent is explicit. | ||
* **Seeking clarity** | ||
```python | ||
def get_user_age(user): | ||
if 'age' in user: | ||
return user['age'] | ||
else: | ||
raise KeyError("User age not found") | ||
``` | ||
* **Guessing** | ||
```python | ||
def get_user_age(user): | ||
return user.get('age', 0) # Assuming age is 0 if not found | ||
``` | ||
|
||
### **_There should be one—and preferably only one—obvious way to do it_** | ||
Python emphasizes having a single, clear way to accomplish a task, reducing confusion and increasing consistency. | ||
|
||
* **One obvious way** | ||
```python | ||
def square(x): | ||
return x * x | ||
``` | ||
* **Multiple ways** | ||
```python | ||
def square(x): | ||
return x ** 2 | ||
``` | ||
|
||
### **_Although that way may not be obvious at first unless you're Dutch_** | ||
This is a humorous nod to Python's creator, Guido van Rossum, who is Dutch. It suggests that the best way may not always be immediately apparent. | ||
|
||
* **Not immediately obvious** | ||
```python | ||
def reverse_string(s): | ||
return s[::-1] # Using slicing to reverse a string | ||
``` | ||
|
||
### **_Now is better than never_** | ||
It's better to take action and write code now rather than procrastinate. | ||
|
||
* **Taking action** | ||
```python | ||
def start_project(): | ||
print("Project started") | ||
|
||
start_project() | ||
``` | ||
|
||
### **_Although never is often better than *right* now_** | ||
However, rushing to write code without proper thought can lead to poor quality. Balance urgency with careful consideration. | ||
|
||
* **Careful consideration** | ||
```python | ||
def start_project(): | ||
# Plan and design before starting | ||
print("Project started after planning") | ||
|
||
start_project() | ||
``` | ||
|
||
### **_If the implementation is hard to explain, it's a bad idea_** | ||
Code should be simple enough to explain easily. If it's too complex to explain, it likely needs to be simplified. | ||
|
||
* **Easy to explain** | ||
```python | ||
def add(a, b): | ||
return a + b | ||
``` | ||
* **Hard to explain** | ||
```python | ||
def add(a, b): | ||
result = 0 | ||
for i in range(a): | ||
result += 1 | ||
for i in range(b): | ||
result += 1 | ||
return result | ||
``` | ||
|
||
### **_If the implementation is easy to explain, it may be a good idea_** | ||
Simple and clear implementations are often the best solutions. | ||
|
||
* **Easy to explain** | ||
```python | ||
def multiply(a, b): | ||
return a * b | ||
``` | ||
|
||
### **_Namespaces are one honking great idea—let's do more of those!_** | ||
Namespaces help organize code and avoid naming conflicts. Use them liberally to keep code clean and modular. | ||
|
||
* **Using namespaces** | ||
```python | ||
import math | ||
print(math.sqrt(16)) # Using the math namespace to access sqrt function | ||
``` | ||
|
||
By embracing these principles and examples, Python developers can write code that is not only functional but also elegant and maintainable. The Zen of Python serves as a timeless guide to achieving coding excellence. | ||
|
||
## References | ||
|
||
- [PEP20](https://peps.python.org/pep-0020/) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters