@@ -374,7 +374,7 @@ When an import is lazy, ``__lazy_import__`` is called instead of
374374``__import__ ``. It adds the module name to ``sys.lazy_modules ``, a set of
375375fully-qualified module names which have been lazily imported at some point
376376(primarily for diagnostics and introspection), and returns a
377- :class: `!types.LazyImportType` ` object for the module.
377+ :class: `!types.LazyImportType ` object for the module.
378378
379379The implementation of ``from ... import `` (the ``IMPORT_FROM `` bytecode
380380implementation) checks if the module it's fetching from is a lazy module
@@ -755,8 +755,8 @@ These changes are limited to bindings explicitly made lazy:
755755 when it is first used.
756756* **Proxy visibility. ** Before first use, the bound name refers to a lazy
757757 proxy. Indirect introspection that touches the value may observe a proxy
758- lazy object representation. After first use (provied the module was
759- imported succesfully ), the name is rebound to the real object and becomes
758+ lazy object representation. After first use (provided the module was
759+ imported successfully ), the name is rebound to the real object and becomes
760760 indistinguishable from an eager import.
761761
762762Thread-safety and reification
@@ -787,7 +787,7 @@ code that doesn't.
787787Runtime performance
788788~~~~~~~~~~~~~~~~~~~
789789
790- After reification (provided the import was succesful ), lazy imports have
790+ After reification (provided the import was successful ), lazy imports have
791791**zero overhead **. The adaptive interpreter specializes the bytecode
792792(typically after 2-3 accesses), eliminating any checks. For example,
793793``LOAD_GLOBAL `` becomes ``LOAD_GLOBAL_MODULE ``, which directly accesses the
0 commit comments