gh-142349: Implement PEP 810 #142351
gh-142349: Implement PEP 810 #142351
Conversation
…s on bad usage of lazy
Highlight lazy imports in the new REPL
|
All commit authors signed the Contributor License Agreement. |
* Update example to add missing import * Add link to lazy keyword * Update documentation
* PEP-7 for import.c * re-order imports * fix tests * some final nits * alter other file * alter sysmodule.c
…ces, and prefer using `//` for comments instead of `/* */`.
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
…ariable names in lazy_import_new
Remove `get_lazy_modules` from docs
| .. c:function:: int PyImport_SetLazyImportsMode(PyImport_LazyImportsMode mode) | ||
| Similar to :c:func:`PyImport_ImportModuleAttr`, but names are UTF-8 encoded |
There was a problem hiding this comment.
Copy-paste error? This seems unrelated to the function being described.
|
|
||
| print('json' in sys.modules) # True - now loaded | ||
|
|
||
| If an error occurs during module loading (such as :exc:`ImportError` or |
There was a problem hiding this comment.
Perhaps also document that ImportCycleError may be raised?
| 1 LOAD_SMALL_INT 0 | ||
| LOAD_CONST 1 (('*',)) | ||
| IMPORT_NAME 0 (math) | ||
| IMPORT_NAME 2 (math + eager) |
There was a problem hiding this comment.
Consider adding more tests for the new logic in dis.py.
| try: | ||
| lazy import os | ||
| except: | ||
| pass |
There was a problem hiding this comment.
What about putting it in the except:?
lazy import within an except block. Also removed unused var.
| The :keyword:`lazy` keyword marks an import as lazy. It is a :ref:`soft keyword | ||
| <soft-keywords>` that only has special meaning when it appears immediately | ||
| before an :keyword:`import` or :keyword:`from` statement. | ||
|
|
||
| When an import statement is preceded by the :keyword:`lazy` keyword, | ||
| the import becomes *lazy*: the module is not loaded immediately at the import | ||
| statement. Instead, a lazy proxy object is created and bound to the name. The | ||
| actual module is loaded on first use of that name. |
There was a problem hiding this comment.
I would recommend swapping the first two paragraphs around, the first sentence "the lazy keyword marks an import as lazy" is not super helpful if you don't define what you mean by "lazy" until the next paragraph 😅
| The :keyword:`lazy` keyword marks an import as lazy. It is a :ref:`soft keyword | |
| <soft-keywords>` that only has special meaning when it appears immediately | |
| before an :keyword:`import` or :keyword:`from` statement. | |
| When an import statement is preceded by the :keyword:`lazy` keyword, | |
| the import becomes *lazy*: the module is not loaded immediately at the import | |
| statement. Instead, a lazy proxy object is created and bound to the name. The | |
| actual module is loaded on first use of that name. | |
| When an import statement is preceded by the :keyword:`lazy` keyword, | |
| the import becomes *lazy*: the module is not loaded immediately at the import | |
| statement. Instead, a lazy proxy object is created and bound to the name. The | |
| actual module is loaded on first use of that name. | |
| The :keyword:`lazy` keyword is a :ref:`soft keyword | |
| <soft-keywords>` that only has special meaning when it appears immediately | |
| before an :keyword:`import` or :keyword:`from` statement. |
There was a problem hiding this comment.
Alternatively, you could keep the same order of the paragraphs but just remove the first sentence
| first used. This gives you the organizational benefits of declaring all | ||
| imports at the top of the file while only paying the loading cost for | ||
| modules you actually use. |
There was a problem hiding this comment.
I think this is a good succinct point explaining why folks would want to use lazy imports - might be worth also mentioning this reasoning in the reference section
14 participants
📚 Documentation preview 📚: https://cpython-previews--142351.org.readthedocs.build/