Python with Braces

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.