Hey all:
There is discussion RIGHT NOW in the SC, and on python-dev about future
"policy" around annotations, in response to the PEP 563 and 649 -- not
clear where it's going to end up, but it is clear that the whole "are
annotations only for typing" question will be made more clear.
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(). However:
In [2]: class Documented(typing.Annotated):
...: pass
...:
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-2-fb09faa96292> in <module>
----> 1 class Documented(typing.Annotated):
2 pass
3
~/miniconda3/envs/py310/lib/python3.10/typing.py in __init_subclass__(cls,
*args, **kwargs)
1676
1677 def __init_subclass__(cls, *args, **kwargs):
-> 1678 raise TypeError(
1679 "Cannot subclass {}.Annotated".format(cls.__module__)
1680 )
TypeError: Cannot subclass __main__.Annotated
So those type objects in typing are weird.
I'm giving up :-(
-CHB
On Tue, Dec 14, 2021 at 8:36 AM Ricky Teachey <ri...@teachey.org> wrote:
> On Tue, Dec 14, 2021 at 10:23 AM Joao S. O. Bueno <jsbu...@python.org.br>
> wrote:
>
>> Just a short one, for everyone agreeing type.Annotated does the job,
>> but thinks we need new syntax, because it is verbose:
>>
>> You can already do:
>>
>> from typing import Annotated as A
>>
>> And:
>>
>> attr: A[type, "docstring goes here"]
>>
>> I see no need for any new syntax.
>>
>> (and maybe adding typing.Docstring for the cases when one
>> just wants the docs, but no type annotation)
>>
>
> You're not wrong exactly. But there has been a desire to reduce the need
> for typing module imports in general, and I think eliminating the need to
> import Annotation for this specific use case might have merit, if is
> becomes blessed as The Way, and if we think it is a good idea to say to
> people "hey! providing docstrings for members is a really good practice,
> and so we're making is super duper easy and standardizing it!" (just as we
> encouraged people to provide docstrings in the past for modules and classes
> by making that syntax dead simple to use).
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
> _______________________________________________
> 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/H5NIEA24YOZOY6TUFIRAYV4IK5FNYQQJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/SF3ZV2H6FV566IQJOUAGAWV6KAPEJT6R/
Code of Conduct: http://python.org/psf/codeofconduct/
