Getting Started with Python: Why Yet Another Scripting Language
I explain the gap Python fills in my polyglot practice, my learning journey, and a PHP developer's perspective on Python.
Last year I started learning Go. When I wrote about that experience, the motivation was clear: Go is a compiled, fast language designed specifically for concurrency. A different tool for a different class of problems. For Python, I couldn’t find that same clear justification for a long time. I already have PHP, I have Go — why Python?
I found the answer in practice, not in theory. A few data transformation jobs, a CSV processing script, some automation needs. I could have written all of them in PHP; I could have written some in Go too. But the libraries written for Python, the tools the Python community has built in these areas, and the language’s readability for this kind of work offered a different experience altogether.
A PHP Developer’s First Impression of Python
I expected syntax shock. It didn’t come. The big differences: no $, no semicolons, no curly braces. Indentation is significant — that’s the only conceptual adjustment required in the first few days.
Type hints felt familiar to anyone accustomed to the post-PHP 7 world; they exist in Python 3 but aren’t mandatory. I prefer to write them anyway: they express the intent of the code clearly.
def process_csv(filepath: str, delimiter: str = ',') -> list[dict]:
import csv
rows = []
with open(filepath, newline='', encoding='utf-8') as f:
reader = csv.DictReader(f, delimiter=delimiter)
for row in reader:
rows.append(dict(row))
return rows
What takes ten lines in PHP takes five in Python. Both languages get the job done, but Python’s standard library has clearly thought ahead for these kinds of tasks.
Python’s Place in a Polyglot Practice
The “do everything in this language” approach to learning a new language never worked for me. I never tried to write all my projects in Go or Python. Instead, I route each language toward the tasks it handles best.
PHP: web applications, APIs, Laravel projects. That’s settled.
Go: long-running processes, CLI tools, services that demand high concurrency.
Python: data transformation scripts, automation, text processing, rapid prototyping. Especially when I want to try something quickly and move on, Python is my first choice.
This distinction has real practical value: setting up Python and writing 10 lines to extract an email list from a CSV is far faster than opening a PHP project and setting up Composer. Right-sized tool for the right-sized job.
The Richness of the Standard Library
The best part of learning Python is the breadth of its standard library. urllib for HTTP requests, json for JSON, datetime for date handling, csv for CSV, re for regular expressions, pathlib for the filesystem — most of this comes with zero dependencies.
I’m not used to that from PHP; there I reach for Composer for a lot of things. A few months into Python I noticed that the bulk of the scripts I was writing only used the standard library.
The Learning Process
Instead of reading a book, I aimed directly at a real need. I had a log file thousands of lines long and needed to find specific patterns. I wrote it in Python. It worked. Then another need came up. Each time, a new module, a new data structure.
The hard part wasn’t object-oriented code — Python supports OOP well. The challenge was what the Python community calls “Pythonic” code: the idiomatic, language-native way of writing things. List comprehensions, context managers, generators — PHP has equivalents for these, but the syntax is different.
# Pythonic: list comprehension
active_users = [u for u in users if u['active']]
# More verbose but familiar
active_users = []
for u in users:
if u['active']:
active_users.append(u)
Both work; the first is more Pythonic. Getting comfortable with that took a few months.
I’m still learning Python — I wouldn’t call myself an expert yet. But I’ve stopped making a distinction between a “second language” and a “third language”: Go and Python are two different tools for two different needs. They’re not here to replace PHP; they’re here to do well the things PHP doesn’t do well.
Comments
Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.