On Sun, Dec 12, 2021 at 03:46:16PM -0800, Christopher Barker wrote: > I know what a wink means, but I have no idea what your actual point is.
My actual point is that the annotation: attr: int is annotating the attribute named "attr". That's pretty basic stuff: if you don't think that we've annotated the attribute attr, then what do you think we've done? Changing int to Annotated[int, metadata]: attr: Annotated[int, metadata] is still annotating attr, not T. What else could it be? The syntax for an annotation is (roughly): name colon object and that's exactly what we have. It's an annotation, and the thing being annotated is attr. I know the docs say: "a type T can be annotated with metadata x via the typehint Annotated[T, x]" but that is wrong and misleading. Better wording would be "a type T can be *associated* with metadata x via the typehint Annotated[T, x]" but that leaves the question, why is this feature called "Annotated"? To me the answer is that it clearly refers to the fact that using this feature, we can annotate attr with *both* T and some additional metadata x, without any restriction on the nature of x. A wrinkle in this is that we can also create new types, using type aliasing: PositiveIntegers = Annotated[int, MinValue(1)] (which, by the way, was one of the motivating use-cases for this feature, so it is important in the big picture of typing, not so important for this use-case though) and in that sense we might say that the new type, PositiveIntegers, is kinda-sorta made from annotating the original type, int, with the metadata. Except... there is no actual annotation there. Its an equals sign, not a colon, so it's a name binding, which the typing system interprets as a type alias. If you look at int, it has no annotations attached, so clearly we haven't annotated int. Which brings us back to my claim that the description is misleading and it should talk about *associating* the type T with the metadata, not annotating it. Semantics are important. Would we be having this argument now if the docs didn't make the (wrong!) claim that it is the type that is being annotated? I don't think so. It is attr being annotated, not the type. And the interpretation of the metadata is entirely up to the consumer of the annotation, which means we are completely entitled to use it for docstrings. > typing.Annotated can exist outside of __annotations__ it is not an > annotation itself, it has special kind of type object (type descriptor? > What the heck do we call things that are used for type hints but are not > regular Python instantiable types?) it’s a container for a type and other > extra information that pertains to that type, not necessarily to the > parameter or whatever it gets attached to. I don't think that there is any general term for types which are only intended for type hints and cannot be instantiated. If such a standard terminology exists, I don't know it. I agree that there should be. > >>> A.__annotations__ > > {'attr': typing.Annotated[int, 'Doc string']} > > > > It's the *class* that is annotated. But note that the mapping is between > > the attribute name to annotation, so in the sense that attributes are > > represented by their name, it is the attribute that is annotated. > > > The attribute got annotated the typing.Annotated object, but what did the > string ‘Doc string’ get attached to? Indirectly to the attribute's name "attr". The implementation uses a special type alias for that purpose. Using a tuple such as (int, 'Doc string') was considered by the PEP but rejected. Nothing in the PEP or the existing docs for Annotated precludes us from using the metadata as a docstring. The interpretation of the metadata has always been up to the consumer of the metadata. -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N4NTXD5EFI75FP7ORSX6DQMIWXQ4U5DR/ Code of Conduct: http://python.org/psf/codeofconduct/