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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/N4NTXD5EFI75FP7ORSX6DQMIWXQ4U5DR/
Code of Conduct: http://python.org/psf/codeofconduct/
