[Python-Dev] PEP 484 update proposal: annotating decorated declarations

Guido van Rossum guido at python.org
Fri Jun 2 13:57:39 EDT 2017


On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven <k7hoven at gmail.com> wrote:

> On Fri, Jun 2, 2017 at 6:34 PM, Naomi Seyfer <naomi at seyfer.org> wrote:
> > Yep, interested in implementing it!  I will put implementation time on my
> > schedule and tell y'all when it is, for holding myself accountable -- it
> > turns out I never do anything not on my schedule.
>
> I still don't understand what would happen with __annotations__. If
> the decorator returns a non-function, one would expect the annotations
> to be in the __annotations__ attribute of the enclosing class or
> module. If it returns a function, they would be in the __annotations__
> attribute of the function. And I'm talking about the runtime behavior
> in Python as explained in PEP484 and PEP526. I would expect these
> declarations to behave according to the same principles as other ways
> to annotate variables/functions. If there is no runtime behavior, a
> comment-based syntax might be more appropriate. Or have I missed
> something?
>

So when returning a function, the runtime version of the decorator can
easily update the function's __annotations__. But when returning a
non-function, the decorator would have a hard time updating __annotations__
of the containing class/module without "cheating" (e.g. sys._getframe()). I
think the latter is similar to e.g. attributes defined with @property --
those don't end up in __annotations__ either. I think this is an acceptable
deficiency.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170602/2315c879/attachment.html>


More information about the Python-Dev mailing list