Fix lint

Author: pablogsal

peps/pep-0810.rst

@@ -95,7 +95,7 @@ applied.
 The mechanism is also **granular**. It is introduced through explicit syntax on
 individual imports, rather than a global flag or implicit setting. This allows
 developers to adopt it incrementally, starting with the most
-performance-sensitive areas of a codebase. As this feature is introduced to the 
+performance-sensitive areas of a codebase. As this feature is introduced to the
 community, we want to make the experience of onboarding optional, progressive, and
 adaptable to the needs of each project.
 
@@ -691,18 +691,18 @@ There are no known security vulnerabilities introduced by lazy imports.
 How to Teach This
 =================
 
-The new ``lazy`` keyword will be documented as part of the language standard. 
+The new ``lazy`` keyword will be documented as part of the language standard.
 
-As this feature is opt-in, new Python users should be able to continue using the 
+As this feature is opt-in, new Python users should be able to continue using the
 language as they are used to. For experienced developers, we expect them to leverage
 lazy imports for the variety of benefits listed above (decreased latency, decreased
 memory usage, etc) on a case-by-case basis. Developers interested in the performance
-of their Python binary will likely leverage profiling to understand the import time 
+of their Python binary will likely leverage profiling to understand the import time
 overhead in their codebase and mark the necessary imports as ``lazy``. In addition,
 developers can mark imports that will only be used for type annotations as ``lazy``.
 
 Below is guidance on how to best take advantage of lazy imports and how to avoid
-incompatibilities: 
+incompatibilities:
 
 * When adopting lazy imports, users should be aware that eliding an import until it is
   used will result in side effects not being executed. In turn, users should be wary of
@@ -1168,7 +1168,7 @@ A: A lazily imported module does **not** appear in ``sys.modules`` until it's re
   result = json.dumps({"key": "value"})  # First use
 
   print('json' in sys.modules)  # True
-  
+
 Reference Implementation
 ========================
 
@@ -1186,7 +1186,7 @@ trade-offs that may be valuable for implementers to consider or for future refin
 Leveraging a Subclass of Dict
 -----------------------------
 
-Instead of updating the internal dict object to directly add the fields needed to support lazy imports, 
+Instead of updating the internal dict object to directly add the fields needed to support lazy imports,
 we could create a subclass of the dict object to be used specifically for Lazy Import enablement. This
 would still be a leaky abstraction though - methods can be called directly such as ``dict.__getitem__``
 and it would impact the performance of globals lookup in the interpreter.
@@ -1195,7 +1195,7 @@ Alternate Keyword Names
 -----------------------
 
 For this PEP, we decided to propose ``lazy`` for the explicit keyword as it felt the most familar to those
-already focused on optimizing import overhead. We also considered a variety of other 
+already focused on optimizing import overhead. We also considered a variety of other
 options to support explicit lazy imports. The most compelling alternates were ``defer`` and ``delay``.
 
 
@@ -1227,13 +1227,13 @@ subtle bugs.
 Support of Import Cycles
 ------------------------
 
-The initial PEP for lazy imports (PEP 690) contained support for eliminating most import cycles, 
-but this meant that in some cases a codebase would no longer run successfully after disabling 
-lazy imports. For the explicit lazy imports PEP we’ve decided not to add support for this use case. 
-While codebases with heavily nested dependencies may benefit from this feature, supporting import 
-cycles runs the risk of creating a dependency on lazy imports. As the intention of this PEP is to 
-give users the power to opt in or opt out of lazy imports based on the specific needs within their 
-codebases, we’ve decided not to implement this feature and instead prioritize backwards compatibility. 
+The initial PEP for lazy imports (PEP 690) contained support for eliminating most import cycles,
+but this meant that in some cases a codebase would no longer run successfully after disabling
+lazy imports. For the explicit lazy imports PEP we’ve decided not to add support for this use case.
+While codebases with heavily nested dependencies may benefit from this feature, supporting import
+cycles runs the risk of creating a dependency on lazy imports. As the intention of this PEP is to
+give users the power to opt in or opt out of lazy imports based on the specific needs within their
+codebases, we’ve decided not to implement this feature and instead prioritize backwards compatibility.
 
 Placing the ``lazy`` Keyword in the Middle of From Imports
 ----------------------------------------------------------
@@ -1245,10 +1245,10 @@ is because ``from foo. lazy import bar`` is legal syntax.
 Placing the ``lazy`` Keyword at the End of Import Statements
 ------------------------------------------------------------
 
-We discussed appending lazy to the end of import statements like such ``import foo lazy`` or 
-``from foo import bar, baz lazy`` but ultimately decided that this approach provided less clarity. 
-For example, if multiple modules are imported in a single statement, it is unclear if the lazy binding 
-applies to all of the imported objects or just a subset of the items. 
+We discussed appending lazy to the end of import statements like such ``import foo lazy`` or
+``from foo import bar, baz lazy`` but ultimately decided that this approach provided less clarity.
+For example, if multiple modules are imported in a single statement, it is unclear if the lazy binding
+applies to all of the imported objects or just a subset of the items.
 
 Returning a Proxy Dict from ``globals()``
 ------------------------------------------