I'm switching to Python and actually liking it

Original Article ↗ Hacker News Discussion ↗

Python on Unix/macOS by Default

  • Several comments challenge the claim that “Python is natively integrated in all Unix distros.”
  • Many Linux distros ship Python by default; BSDs often don’t.
  • macOS used to bundle Python 2.7; it was removed (mid‑Monterey), leaving only a shim that prompts to install developer tools.
  • Some see removal as good (avoid outdated system interpreters, reduce security/maintenance burden); others found the mid-cycle removal of Python 2 disruptive and poorly managed.

Dunder Methods and Syntax Debates

  • Big subthread on __init__, __new__, and dunder naming.
  • Critics: visually noisy, “underscore madness,” non-keyword special names feel like a hack compared to constructor/operator+.
  • Defenders:
    • Double underscores clearly mark “magic” methods and keep them out of normal APIs.
    • They’re only seen in definitions; users call normal syntax (obj + x, MyClass(...)).
    • Other languages (PHP, Lua, JS symbols, C/C++ macros) do similar things.
  • Related: explanation of Python’s four name styles (foo, _foo, __foo, __foo__) and name-mangling behavior.

Packaging, Virtual Environments, and uv

  • Strong consensus that historical Python packaging/env management has been painful, especially with native extensions (NumPy, SciPy, BLAS/LAPACK).
  • Complaints: broken pip workflows, version conflicts, fragile old projects, need for Docker or Conda to get repeatability.
  • Counterpoints:
    • For pure-Python libs, venv + pip can be fine; many large production systems run reliably.
    • Problems often stem from C/Fortran deps and ecosystem inconsistency, not the language itself.
  • uv is widely praised as a step‑change: fast, unifies env creation, dependency resolution, tool installation (uvx / uv tool), and can abstract away manual venv activation. Speculation that uv may become the de facto standard.

Python’s Role, Popularity, and History

  • Several timelines: from sysadmin “Swiss army knife,” to early web frameworks (Zope, Django, CherryPy), to scientific computing (Numeric → NumPy, SciPy, Pandas, Matplotlib, scikit‑learn), to data science/ML and now LLM tooling.
  • Debate on whether Python’s success is driven mainly by entry-level courses vs. earlier industrial and scientific adoption.
  • Many describe Python as “second best language for any job” or “closest to executable pseudocode,” favored for glue code, data processing, and ML, with other languages (Java, Go, Rust, TypeScript, C#) preferred for large, strongly-typed systems.

Language Preferences and Pain Points

  • Enthusiasts: enjoy readability, huge ecosystem, batteries-included stdlib, and modern tooling (uv, ruff, pydantic, FastAPI, Jupyter).
  • Skeptics:
    • Dynamic typing and late errors; large Python codebases feel fragile vs. Rust/Go/TS.
    • Async/asyncio ergonomics, GIL, and debugging across Python/C++ boundaries.
    • Significant whitespace and scoping quirks (loop variables leaking, exception-variable behavior).
  • Some report switching away from Python (to JS/TS, Rust, Go) for better typing, tooling, or concurrency; others are moving to Python because of AI/ML libraries and LLM-centric tooling.

Tooling, Project Structure, and Monorepos

  • Common “modern Python stack” echoed:
    • uv for envs/deps, ruff for lint/format, sometimes ty for typing checks, pydantic or dataclasses for data models.
    • FastAPI or similar for web APIs; Make or just as task runners.
  • Some favor monorepos (especially for small teams or personal projects); others report monorepo dependency tangles and prefer service‑ or area‑based repos.
  • Cookiecutter, Copier, and similar templating tools are recommended for bootstrapping consistent project layouts.