[Python-ideas] Was: Annotations (and static typing), Now:Sharing __annotations__
Cem Karan
cfkaran2 at gmail.com
Mon Aug 25 01:17:46 CEST 2014
On Aug 24, 2014, at 6:17 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> On 24 August 2014 03:18, Cem Karan <cfkaran2 at gmail.com> wrote:
>>> Each project (and 'project' is a very
>>> loosely defined concept here) chooses a UUID that it uses as key into the
>>> dictionary.
>
> Please, not UUIDs. As something meant to be used by
> humans, they're horrible.
>
> --
> Greg
I understand your concerns about them, I really, really do. But can you think of a better way? All my prior points still hold. In my mind, UUIDs are the least bad alternative. We have to educate people as to what the annotations dictionary standard is, and then encourage libraries to use the standard and to hide the UUIDs from end users. My code does this already; if someone wants me to extend it in some way, put in a request, and I will. If the PSF wants it in the standard library, it's theirs! Please, download it and play with it, it's short to the point of almost being trivial (https://github.com/oranguman/annotizer).
Don't let the fact that the bare __annotations__ dict is going to look ugly; if we try to get a really powerful typing system in there, people will probably not want to write the annotations by hand anyways for the simple reason that it will be too hard to read. I mean, which would you rather read?
"""
@doc(a, "docs about a")
@type(a, set(range(10)))
def foo(a):
pass
def bar(a: {__docs_project_ID: "docs about a", __types_project_ID: set(range(10))}):
pass
"""
Even if __project_ID was something human readable, that line would be PAINFUL for a human to parse. UUIDs won't make it much worse, and they do avoid a lot of the other headaches.
Thanks,
Cem Karan
More information about the Python-ideas
mailing list