On Fri, 26 Nov 2021 at 05:14, Guido van Rossum <gu...@python.org> wrote: > > My memory is also hazy, but I'm quite sure that *in my mind* annotations were > intended as a compromise between conflicting proposals for *typing*. We > didn't have agreement on the syntax or semantics, but we did know we wanted > to do something with types eventually.
More hazy memories here, but I think the original proposal left open the possibility of annotations not being types at all - for example, being docstrings for the arguments, or option names for a "function call to CLI" tool, etc. I think that some libraries took this approach (in particular the "CLI builder" idea). At some point (probably around PEP 484) it became clear that the expectation was that annotations would be *types*, and in particular would be the expected/intended type of the annotated value. I think there was some discussion at that point about "what do we do about the CLI builders" but the conclusion was that they had relatively low adoption rates, and could adapt (or more accurately, abandon the annotation approach). That was the point, in my recollection, where the "annotations are for types" principle was established. However, I feel that many people got (or were given) the impression that static type checkers were the core use case (probably as a result of the emphasis on the message that "type annotations will never be mandatory"), for better or worse. I think that by now, it's long been understood by most people that annotations are types. This may actually be one reason why people are so uncomfortable with the idea of stringified annotations, because it violates that assumption - personally, I have the same discomfort about using explicit string annotations for forward references, it feels like I'm not declaring a "proper type". If what I say above is right, the debate here isn't about whether annotations "are for types", but rather about whether reading the types in annotations and using them to affect behaviour *at runtime* is a legitimate use of annotations. That is the use case that stringifying annotations makes more difficult, and which doesn't seem to have a strong enough voice in the direction of typing proposals. I lurk on the typing-sig, and from an outsider's perspective, the participants seem to be almost entirely designers or heavy users of static type checkers. That gives a certain emphasis to the proposals coming from that group. I'd therefore interpret Barry's plea as being for *anyone* with a use for annotations to provide their feedback (at least, anyone who accepts that annotations are types), with particular emphasis on people who want to use the types declared in annotations to affect runtime behaviour, as that's the most under-represented group at the moment (and it's not clear whether it's under-represented because there aren't many such uses, or because the users aren't being heard from). Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5N5GTSWQPVALCTJDWZ4G4JSBPDS6324V/ Code of Conduct: http://python.org/psf/codeofconduct/
