@@ -326,6 +326,8 @@ from within the language. Therefore it's possible to write code
326326that behaves differently based on whether annotations are
327327evaluated at binding time or at access time, e.g.
328328
329+ .. code-block ::
330+
329331 mytype = str
330332 def foo(a:mytype): pass
331333 mytype = int
@@ -364,7 +366,7 @@ module-level scope:
364366 IMO the inability of referencing class-level definitions
365367 from annotations on methods pretty much kills this idea.
366368
367- https://mail.python.org/pipermail/python-dev/2017-November/150109.html
369+ https://mail.python.org/pipermail/python-dev/2017-November/150109.html
368370
369371This led to a short discussion about extending lambda-ized
370372annotations for methods to be able to refer to class-level
@@ -373,7 +375,7 @@ scope. This idea, too, was quickly rejected.
373375
374376PEP 563 summarizes the above discussion here:
375377
376- https://www.python.org/dev/peps/pep-0563/#keeping-the-ability-to-use-function-local-state-when-defining-annotations
378+ https://www.python.org/dev/peps/pep-0563/#keeping-the-ability-to-use-function-local-state-when-defining-annotations
377379
378380What's puzzling is PEP 563's own changes to the scoping rules
379381of annotations—it *also * doesn't permit annotations to reference
@@ -400,7 +402,7 @@ Implementation
400402
401403There's a prototype implementation of this PEP, here:
402404
403- https://github.com/larryhastings/co_annotations/
405+ https://github.com/larryhastings/co_annotations/
404406
405407As of this writing, all features described in this PEP are
406408implemented, and there are some rudimentary tests in the
0 commit comments