Show HN: Localscope–Limit scope of Python functions for reproducible execution

Nice! This approach can be used to implement coeffects (as e.g. seen in Hack [1]), by only passing explicit effect-producing objects. Imagine a function that's guaranteed to not write to any files, because it can't access `open()`, or can only access a version of `open()` that only accepts read-only access.

[1]: https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...

I was curious how this works - it's using the Python standard library disassembler: https://docs.python.org/3/library/dis.html

    for instruction in dis.get_instructions(code):
        ...

Simple localscope in TXR Lisp:

  $ txr -i localscope.tl
  Pour le service en la langue Shell, appuyez sur Ctrl-D.
  1> (localscope (+ %pi% %pi%)) ;; OK, %pi% is built-in
  6.28318530717959
  2> (localscope *print-base*) ;; likewise
  10
  3> (localscope (+ a b c)) ;; bad
  ** expr-3:1: localscope: global variables (c b a) used

  (defmacro localscope (:form f :env e . forms)
    (let ((body ^(progn ,*forms)))
      (tree-bind (exp fv-inner ff-inner fv-outer ff-outer) (expand-with-free-refs
                                                             body e)
        (ignore ff-inner fv-outer ff-outer)
        (let* ((usr (find-package :usr))
               (globals [keep-if (do or (not (boundp @1))
                                        (neq (symbol-package @1) usr))
                                 fv-inner]))
          (if globals
            (compile-error f "global variables ~s used" globals)))
        body)))

I wrote myself a similar decorator for a completely different purpose – ensuring a function I'm going to serialise over the network doesn't have any outside dependencies

This is actually a cleaner API so might switch my code to it, amazing work

This looks like a handy tool, especially for catching unintended global variable access in environments like Jupyter notebooks, where scope bugs can easily creep in. The ability to disassemble functions and analyze their dependencies could be particularly useful for debugging and enforcing best practices in functional programming, as seen in JAX.

Would be interesting to see how it compares to static analysis tools like mypy or linters—does it catch edge cases they might miss? Nice work!

> Everything works nicely, and you package the code in a function for later use but forget about the scale factor introduced earlier in the notebook.

You see a problem, you fix it with library, and I applaud that. You have to wonder though, how many years does it take for a reproducible notebook environment to implement out of scope variable guards..

Since I've started using Jupyter notebooks, I've wanted a feature to "undo" running a cell. This feels so important to for spontaneous exploration. This work feels like an important building block for this!

I have this idea of tools which help you do the right thing and tools that let you do the wrong thing longer. Jupyter is already the latter sort of tool, and this is the bad kind of tool on top of the bad kind of tool.

> Have you ever hunted bugs caused by accidentally using a global variable in a function in a Jupyter notebook?

Nope!

> Have you ever scratched your head because your code broke after restarting the Python kernel?

Also nope!

I'm technically a data scientist but I don't use notebooks very often. Even when I did, though, I can't recall having this error very often. Is this really necessary? Anyway, this kind of thing is only useful if people adopt it. The people who are likely to install this tool and use it probably already avoid this issue while the people who have this issue will never hear of this tool or will not consistently employ it.

I guess I'm just salty from years of dealing with people who give their Python code half-hearted incorrect type hints but never run a static type checker on their code.

But how can you make sure that people annotate their functions with localscope?

Maybe I'm being naive, but it feels like if this is a problem for people they should be looking at how they write their code, not reaching for a library.

If you don't want pyhton flavored scope and lifetime rules, use another language :emothonless-face: