Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Good feature but god I hate there’s a whole new keyword for a minor modification on an existing concept. Very unnecessary.
  • It's a soft keyword: https://docs.python.org/3.15/reference/lexical_analysis.html...

    > As soft keywords, their use in the grammar is possible while still preserving compatibility with existing code that uses these names as identifier names.

  • Or just use C++. The Python ecosystem is just bloat, blogs and tools.
  • Is there a language with a hybrid laziness approach? similar to "do work only if needed" but if you have ressources, do work most likely to be needed, like lazy anticipating?
  • This seems like an ugly hack. We really need a way to snapshot a python program after its imports have been loaded, similar to temacs/emacs that's been around for decades, or a similar thing that exists in gforth. Emacs's old unexec scheme became unmaintainable but maybe there are still good alternate ways to do it.
  • This feature seems really valuable for commandline tools! However this paragraph gave me pause:

    > Currently, disabling lazy imports disabled the syntax keyword, which means that you can’t use it for circular imports, type checking, etc.

    Imo this is a good thing, laziness shouldn't be semantically important. The ability to force disable laziness while maintaining semantics is important for linting and testing, and more often than not, circular imports are a sign of bad code structure.

  • I've got my reservations about lazy imports, but scipy in particular is such a memory hog, I've increasingly been vendoring smaller utilities out of it. Good lazy imports would be a big help.
  • doesn't `from scipy import ...` help with memory?
  • > This pattern, for example, can’t be lazy: try: import numpy; except ModuleNotFoundError: ...

    Wait, that seems bad. These kinds of modules (especially numba) are often exactly the ones that you want to delay importing. Why not provide a way to check the existence at import time? How are you supposed to handle nonexistence in that case?

  • ...crash?

    Seriously: crash if your dependencies aren't available. There are better ways to do optional dependencies. ImportError ain't it.

  • > The error here will move to the first usage of something from numpy. There is a semi-lazy alternative:

      import importlib.util
    
      if importlib.util.find_spec("numpy") is None:
      ... # whatever you wanted to do if numpy is missing
    
      lazy import numpy
    by js2