Christopher Barker writes:
> but it is clear that the whole "are annotations only for typing"
> question will be made more clear.
Can we please stop posting this? AFAICS, the basic principle is
absolutely clear. For the foreseeable future:
1. Annotations are NOT "only for typing".
2. Uses of annotations that get in the way of typing will be NOT
adopted or enabled in the Python language, builtins, or stdlib.
3. typing.Annotated means that there is no conflict between 1 and 2,
although there may be inconvenience, ugliness, or lower
performance implied for some non-typing applications.
Guido and the typing PEP authors have stated 1 (repeatedly!) and 2
(more recently) below. However, the definition of "typing" may get
clarified, if that's what you mean (runtime vs. static, are
dataclasses a typing use case, etc).
> Anyway, I had the idea that one could create a subclass of
> typing.Annotated, and call it "Documented", and then have it do
> something a little special, while still looking like an Annotated
> to the Typing system, e.g. get_type_hints().
I imagine this can be done by a Sufficiently Persistent Pythonista,
but I suppose a factory function would be easier. I have PoC (too
embarrassing to post) given the existence of an open slot in Annotated
instances (see below).
The main problems (as pointed out by multiple Steves) are
- Any *syntax* (language change) for creating docstrings MUST be
approved by the SC, and given the rejection of PEP 224 (exactly the
original proposal for "docstrings below attributes and variables")
and the bikeshedding that already has taken place in this iteration,
this could take years.
- Any change to help(), which is a builtin, will require SC
approval, and great care will have to be taken with the design
i.e. #2 above for sure, and #3 should be minimized.
By #3 be minimized I have in mind that there are probably existing
clients that moved to annotated and expect their strings as the second
argument to Annotated[]. It would be rude to make them move again.
So that kind of convention for the use of Annotated.__metadata__
should be avoided IMO.
Although Annotated can't be subclassed, a minimal, noninvasive, change
to Annotated that makes both #2 and #3 possible would be adding a new
slot __attr_doc__ into which to stuff the docstring. That could be
done with a class of a different name for experimentation. This would
give people working out how to use this info in help() a single
protocol for getting the docstring (even if in the end there's a
different protocol used in typing.Annotated, it should be amenable to
abstraction, making adaptation to a new protocol simple). Another
possibility would be a specific new type DocstringType that could be
placed anywhere in __metadata__ and the first instance would be
considered the docstring for the identifier so Annotated.
I really do think that if we can keep a lid on the bikeshedding this
could be in 3.11.
Note that the DocstringType approach doesn't get around the SC because
we still want to change help() to recognize these docstrings.
_______________________________________________
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/I2URHK5P4HV4JFMA6B6JMJ3LLCACCCFM/
Code of Conduct: http://python.org/psf/codeofconduct/
