[Python-ideas] Was: Annotations (and static typing), Now:Sharing __annotations__

[Andrew Barnert]

On Aug 24, 2014, at 16:17, Cem Karan <cfkaran2 at gmail.com> wrote:

> 
> 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
> """

Or:

@doc(a, "docs about a")
def foo(a: set[10]):
    pass

Why does doc have to set an annotation in the first place? Annotations are just syntactic sugar for sticking stuff in a dict attached to the function as an attribute; when that syntactic sugar doesn't make your code more readable, there's no benefit at all to annotations. You could just make the @doc decorator store and find its stuff in a special __docinfo__ attribute instead, and it will look exactly the same to your users.

The only question is: which data should be privileges to use the syntactic sugar? That's up to each project to decide; all Guido is suggesting is that we add a default presumption that it's the MyPy-style static types that get to use annotations.

As a side note, I'm not sure how your decorator syntax is going to work unless you've predefined a global named "a" with some kind of value that can be used to match parameters named "a". While there might be some way to do that dynamically (create a module subclass with a custom __dict__ that implements __missing__, and an import hook that applies that to your modules?), it seems pretty hacky, and doesn't buy you that much.