Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a great compromise given how much would break if this was the default. Making this the default would be better in the long-run, require taming the abuse of side-effects in imports too, win-win.

If one could dream, modules should have to explicitly declare whether they have side-effects or not, with a marker at the top of the module. Not declaring this and trying anything except declaring a function or class should lead to type-checker errors. Modules declaring this pure-marker then automatically become lazy. Others should require explicit "import_with_side_effects" keyword.

    __pure__ = True
    import logging 
    import threading
  
    app = Flask()          # << ImpureError
    sys.path.append()      # << ImpureError
    with open(.. )         # << ImpureError
    logging.basicSetup()   # << ImpureError
    if foo:                # << ImpureError  (arguable)
   
    @app.route("/foo")     # Questionable
    def serve():           # OK
        ...

    serve()                # << ImpureError
    t = threading.Thread(target=serve) # << ImpureError

All of this would be impossible today, given how much the Python relies on metaprogramming. Even standard library exposes functions to create classes on the fly like Enum and dataclasses, that are difficult to assert as either pure or impure. With more and more of the ecosystem embracing typed Python, this metaprogramming is reducing into a less dynamic subset. Type checkers and LSPs must have at least some awareness of these modules, without executing them as plain python-code.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: