Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

discuss.python.org

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#51

Post by GauntletWizard »

lairv wrote: post #44
notatallshaw wrote: post #35

Earlier quoted context omitted.

Python has about 40 keywords, I say I would regularly use about 30, and irregularly use about another 5. Hardly seems like a "junkyard". Further, this lack of first class support for lazy importing has spawned multiple CPython forks that implement their own lazy importing or a modified version of the prior rejected PEP 690. Reducing the real world need for forks seems worth the price of one keyword.

For those curious here are the actual keywords (from https://docs.python.org/3/reference/lexical_analysis.html?ut... ) Hard Keywords: False await else import pass None break except in raise True class finally is return and continue for lambda try as def from nonlocal while assert del global not with async elif if or yield Soft Keywords: match case _ type I think nonlocal/global are the only hard keywords I now barely…

Removing "print" in 3.0 helped their case significantly, as well.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#52

Post by falcor84 »

zahlman wrote: post #49
falcor84 wrote: post #37

Earlier quoted context omitted.

If you want even better nightmares, you can make localhost:8000 forward to a container running claude code with --dangerously-skip-permissions which uses an unkindness of mcp servers to control that endpoint on the fly based (amongst other sources) on 4chan's /b/.

> which uses an unkindness of mcp servers I guess you meant "a feature of MCP servers which is unkind", but I couldn't help but interpret "unkindness" as the collective noun for a group of MCP servers.

That was indeed the intent. I first considered "a conspiracy" like with lemurs, but eventually felt that "unkindness" was more appropriate.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#53

Post by silverwind »

lairv wrote: post #44
notatallshaw wrote: post #35

Earlier quoted context omitted.

Python has about 40 keywords, I say I would regularly use about 30, and irregularly use about another 5. Hardly seems like a "junkyard". Further, this lack of first class support for lazy importing has spawned multiple CPython forks that implement their own lazy importing or a modified version of the prior rejected PEP 690. Reducing the real world need for forks seems worth the price of one keyword.

For those curious here are the actual keywords (from https://docs.python.org/3/reference/lexical_analysis.html?ut... ) Hard Keywords: False await else import pass None break except in raise True class finally is return and continue for lambda try as def from nonlocal while assert del global not with async elif if or yield Soft Keywords: match case _ type I think nonlocal/global are the only hard keywords I now barely…

I recall when they added "async" and it broken a whole lot of libraries. I hope they never again introduce new "hard" keywords.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#54

Post by belval »

onedognight wrote: post #42
nothrowaways wrote: post #31

Python is quickly turning into a crowded keyword junkyard

The pep didn’t mention considering reusing `async` instead of `lazy`. That would’ve conveyed the same thing to me without a new keyword, and would haven’t been similar to html’s usage `async`.

I personally would have preferred "defer import os" instead of "lazy import os". It might be the non-native showing but lazy import feels unserious.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#55

Post by divbzero »

How will lazy imports interact with PEP 8 which recommends grouping imports in order:

1. Standard library imports.

2. Related third party imports.

3. Local application/library specific imports.

https://peps.python.org/pep-0008/#imports

Based on the examples in PEP 810, I suppose each group of regular imports can be followed by a group of lazy imports?

  import os
  import sys
  
  lazy import json
  
  import fastapi
  
  lazy import numpy
  
  import myapi
  import mymodels
  
  lazy import myutils
  
  ...

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#56

Post by bloppe »

belval wrote: post #54
onedognight wrote: post #42

Earlier quoted context omitted.

The pep didn’t mention considering reusing `async` instead of `lazy`. That would’ve conveyed the same thing to me without a new keyword, and would haven’t been similar to html’s usage `async`.

I personally would have preferred "defer import os" instead of "lazy import os". It might be the non-native showing but lazy import feels unserious.

Lazy is more canonical: https://en.wikipedia.org/wiki/Lazy_evaluation

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#57

Post by aroberge »

nothrowaways wrote: post #31

Python is quickly turning into a crowded keyword junkyard

> Python is quickly turning into a crowded keyword junkyard

* Javascript (ECMAScript) has 63 keywords. * Rust has 50 keywords. * Java has 51 keywords + 17 contextually reserved words, for a total of 68. * Python has now 36 keywords + 4 'soft' keywords, for a total of 40. * Go has 25 keywords.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#58

Post by ta371jashgG »

This has been rejected several times before. Now that Google and Microsoft fired core developers, Python Inc. is owned by Meta. Meta supports lazy imports in Cinder and needs it for its atrocious and bloated scientific ecosystem so that the bloat loads in less than 5 min.

If Meta also starts firing Python developers, development might return to normal.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#59

Post by _moof »

belval wrote: post #54
onedognight wrote: post #42

Earlier quoted context omitted.

The pep didn’t mention considering reusing `async` instead of `lazy`. That would’ve conveyed the same thing to me without a new keyword, and would haven’t been similar to html’s usage `async`.

I personally would have preferred "defer import os" instead of "lazy import os". It might be the non-native showing but lazy import feels unserious.

"Lazy" is standard language for this kind of behavior.

Re: Python Steering Council unanimously accepts "PEP 810, Explicit lazy imports"

#60

Post by markrages »

skywhopper wrote: post #16
markrages wrote: post #5

Earlier quoted context omitted.

You have always been able to do the same thing in Python. This PEP isn't needed for that functionality.

You can declare imports at the beginning of a program that don’t load until they are used?

"defining them right before the dependency is actually used"
Post reply on HN