Python with Braces

Original Article ↗ Hacker News Discussion ↗

A small Python-to-Python transpiler that adds C-style braces to the language reignites long‑running arguments over significant whitespace, readability, and whether block structure should be enforced by syntax or by tools. Commenters weigh the cognitive load of indentation against the visual noise of braces and semicolons, point to editor features and auto-formatters like Black as more practical solutions, and explore ideas like AST-based source representations where each developer could view code in their preferred style. Many see the project as a fun experiment rather than something production-ready, but it serves as a springboard for broader questions about how much syntax should matter in modern programming.

Braces vs Python’s Significant Whitespace

  • Many participants dislike relying solely on indentation for structure; they find deep nesting hard to track and consider braces a clearer, redundant signal.
  • Others argue indentation is perfectly readable for reasonably sized functions; very deep nesting is itself a design smell.
  • Some like Python’s minimal syntax and say braces add visual noise and cognitive load.
  • A recurring joke: Python already “supports” braces via comments (e.g., #{ / #}) and with fonts/linters they can behave like real block markers.

Editor Tooling, Indentation, and Formatters

  • Pro‑whitespace commenters say modern editors solve most indentation pain:
    • Indent guides, showing whitespace, auto-format-on-save, and refactoring tools.
    • Python formatters (Black, Ruff) are praised for removing style bikeshedding; Go’s gofmt and Rust’s cargo fmt play similar roles.
  • Critics point out tooling doesn’t always exist in web UIs (GitHub diffs, merge requests) and not everyone uses heavy IDEs.
  • Some like adding explicit “pseudo‑braces” in comments plus tooling to cross-check indentation against them.

Semicolons, Statement Boundaries, and Expressions

  • Many consider mandatory semicolons “noise” since line breaks are visually obvious; Go and Python’s approach (optional semicolons) is cited approvingly.
  • Others defend semicolons as useful redundancy, especially with long, horizontally complex code or expression-oriented languages like Rust, where semicolons distinguish expressions from statements.
  • JavaScript’s automatic semicolon insertion is criticized as error-prone; Go’s algorithm is seen as safer and simpler.

Alternative Syntaxes and AST‑Centric Editing

  • Several comments wish syntax were a mere view over an AST:
    • Different users could see braces, indentation, or other notations while sharing one canonical structure.
    • This could enable semantic diffs and refactor-aware merges instead of text diffs.
  • Objections:
    • Harder sharing (snippets, blogs), loss of simple text tooling (grep, sed), and risk of proprietary, non-human-readable formats.
    • Style debates would just move to editor-layer representations.
  • Related projects are mentioned: Unison’s AST storage, Lisp/S-expression approaches, structural editors, projectional editing, and JVM/CIL decompilation as partial precedents.

Broader Views on Python

  • Some see whitespace sensitivity as a minor annoyance relative to deeper issues (performance, async, scoping), others as a core readability win that encourages cleaner code.
  • There is both affection for Python’s “executable pseudocode” feel and sharp criticism of its syntax decisions and ecosystem politics.
  • Multiple people note they’d rather spend energy on tests, design, and tooling than on brace/whitespace debates at all.