On Wed, Mar 5, 2014 at 8:45 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 5 Mar 2014 22:51, "Paul Moore" <p.f.moore@gmail.com> wrote:
>
> On 5 March 2014 11:53, Cem Karan <cfkaran2@gmail.com> wrote:
> > Thoughts/suggestions?
>
> I think the core/stdlib position is that agreeing conventions would be
> better done once some real world experience of the practical issues
> and benefits of annotations has been established.

MyPy uses function annotations for optional static typing, which is pretty much the use case Guido originally had in mind and the main reason that PEP 8 doesn't make combining annotations with an associated decorator mandatory: http://www.mypy-lang.org/

You do still have to import a particular module to indicate that all annotations in the importing module are to be interpreted as type annotations.

Beyond that, the guidance in PEP 8 stands:

"""It is recommended that third party experiments with annotations use an associated decorator to indicate how the annotation should be interpreted."""

I like what all of you are suggesting; decorators are the way to go. If a project defines its own annotation decorators as sigtools.modifiers.annotate, mypy, or pyanno do, then it shouldn't be too hard for a project to add its own UUID to the annotation dictionary. I'll spend a little while this weekend seeing if I can come up with some proof-of-concept code to make this work in a portable way. If the signatures looked vaguely like the following:

@type_annotation(some_arg, int)
@return_type_annotation(int)
def function(some_arg):
pass

Would that be appealing to everyone?

One question though, are we allowed to modify a functions __annotation__ dictionary directly? I know that I can do it, I just don't know if it is discouraged.

Thanks,
Cem Karan