Hacker News Reader

Comment by andreareina | Hacker News Reader

I have a long but pretty linear function whose job it is to take a whole mess of data and build a SAT model. Even with even with jump-to-definition etc lots of little[1] sub-functions make the coffee difficult to read. I would kill for block scope (yay python) to ensure that I'm not accidentally reusing a temporary variable from three steps ago.

[1] honestly, not so little

View on HN

Hmm. Now you've got me thinking about the most ergonomic way do define a block in python. Maybe a no-op context manager? So you could do "with scope():"

I admit to using block scopes in rust a fair bit

Plain context manager doesn't actually introduce a new scope:

    with open("foo") as f:
        s = f.read()
    print(f) # closed file object still exists

A macro that looks like a context manager would work but beware the edge cases.

Ignoring any future/proposed syntax, I think the most block-like would be a local function definition which you then call once right afterward. This is the same you would do in any LISP-like language.

It could take zero arguments if you just want to temporarily extend the current scope with a few more variable-binding statements. Or, it could also have arguments if you want to do a "let" like construct to rename some expression results in the outer (calling) scope during the invocation.

  # ... outer scope
  x = expr1
  y = expr2
  r1 = None
  r2 = None
  
  def block1():
    nonlocal r1
    z = expr3
    r1 = expr4
  block1()
  
  def block2(x, y):
    nonlocal r2
    z = expr5
    r2 = expr6
  block2(expr7, expr8)

Edited for typos, code formatting, and bugs ;-).

Reply on news.ycombinator.com