It's certainly not my goal to be misleading. Here's my
perspective.
In Python, if you evaluate an undefined name, Python raises a NameError. This is so consistent I'm willing to call it a "rule". Various folks have proposed an exception to this "rule": evaluating an undefined name in an PEP 649 delayed annotation wouldn't raise NameError, instead evaluating to some yet-to-be-determined value (ForwardRef, AnnotationName, etc). I don't think annotations are special enough to "break the rules" in this way.
Certainly this has the potential to be irritating for code using annotations at runtime, e.g. Pydantic. Instead of catching the exception, it'd have to check for this substitute value. I'm not sure if the idea is to substitute for the entire annotation, or for just the value that raised NameError; if the latter, Pydantic et al would have to iterate over every value in an annotation to look for this special value.
As a consumer of annotations at runtime, I'd definitely prefer
that they raise NameError rather than silently substitute in this
alternative value.
/arry
On Thu, Oct 21, 2021 at 10:35 AM Larry Hastings <larry@hastings.org> wrote:
.Your proposal is one of several suggesting that type annotations are special enough to break the rules. I don't like this idea. But you'll be pleased to know there are a lot of folks in the "suppress the NameError" faction, including Guido (IIUC).
Yes, I still want this part of your PEP changed. I find your characterization of my position misleading -- there is no rule to break here(*), just an API.
(*) The Zen of Python does not have rules.
--
--Guido van Rossum (python.org/~guido)Pronouns: he/him (why is my pronoun here?)