Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations
On Tue, May 9, 2017 at 8:19 PM, Guido van Rossum wrote: > There's a PR to the peps proposal here: > https://github.com/python/peps/pull/242 > > The full text of the current proposal is below. The motivation for this is > that for complex decorators, even if the type checker can figure out what's > going on (by taking the signature of the decorator into account), it's > sometimes helpful to the human reader of the code to be reminded of the type > after applying the decorators (or a stack thereof). Much discussion can be > found in the PR. Note that we ended up having `Callable` in the type because > there's no rule that says a decorator returns a function type (e.g. > `property` doesn't). > > This is a small thing but I'd like to run it by a larger audience than the > core mypy devs who have commented so far. There was a brief discussion on > python-ideas (my original, favorable reply by Nick, my response). > > Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan > Levkivskyi and Jukka Lehtosalo. > > If there's no further debate here I'll merge it into the PEP and an > implementation will hopefully appear in the next version of the typing > module (also hopefully to be included in CPython 3.6.2 and 3.5.4). > So the change would only affect early adopters of this typing feature, who are likely to upgrade to newer python versions often? Could this be called a 3.7 feature with a clearly documented bonus that it also works in 3.6.2+ and 3.5.4+? I mean, to prevent 3rd-party libraries tested with 3.5(.4) from being broken in 3.5.3? > Here's the proposed text (wordsmithing suggestions in the PR please): > > +Decorators > +-- > + > +Decorators can modify the types of the functions or classes they > +decorate. Use the ``decorated_type`` decorator to declare the type of > +the resulting item after all other decorators have been applied:: > + > + from typing import ContextManager, Iterator, decorated_type > + from contextlib import contextmanager > + > + class DatabaseSession: ... > + > + @decorated_type(Callable[[str], ContextManager[DatabaseSession]]) > + @contextmanager > + def session(url: str) -> Iterator[DatabaseSession]: > + s = DatabaseSession(url) > + try: > + yield s > + finally: > + s.close() > + > +The argument of ``decorated_type`` is a type annotation on the name > +being declared (``session``, in the example above). If you have > +multiple decorators, ``decorated_type`` must be topmost. The > +``decorated_type`` decorator is invalid on a function declaration that > +is also decorated with ``overload``, but you can annotate the > +implementation of the overload series with ``decorated_type``. > + > Would __annotations__ be set by the decorator? To me, not setting them would seem weird, but cases where the result is not a function could be weird. I also don't see a mention of this only working in stubs. I like Jukka's version, as it has a clear distinction between functions and other attributes. But that might require a language change to provide __annotations__ in a clean manner? Maybe that language change would be useful elsewhere. —Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations
On 15 May 2017 at 10:48, Koos Zevenhoven wrote: > > Here's the proposed text (wordsmithing suggestions in the PR please): > > > > +Decorators > > +-- > > + > > +Decorators can modify the types of the functions or classes they > > +decorate. Use the ``decorated_type`` decorator to declare the type of > > +the resulting item after all other decorators have been applied:: > > + > > + from typing import ContextManager, Iterator, decorated_type > > + from contextlib import contextmanager > > + > > + class DatabaseSession: ... > > + > > + @decorated_type(Callable[[str], ContextManager[DatabaseSession]]) > > + @contextmanager > > + def session(url: str) -> Iterator[DatabaseSession]: > > + s = DatabaseSession(url) > > + try: > > + yield s > > + finally: > > + s.close() > > + > > +The argument of ``decorated_type`` is a type annotation on the name > > +being declared (``session``, in the example above). If you have > > +multiple decorators, ``decorated_type`` must be topmost. The > > +``decorated_type`` decorator is invalid on a function declaration that > > +is also decorated with ``overload``, but you can annotate the > > +implementation of the overload series with ``decorated_type``. > > + > > > > Would __annotations__ be set by the decorator? To me, not setting them > would seem weird, but cases where the result is not a function could > be weird. I also don't see a mention of this only working in stubs. > > I like Jukka's version, as it has a clear distinction between > functions and other attributes. But that might require a language > change to provide __annotations__ in a clean manner? Maybe that > language change would be useful elsewhere. With original syntax it is possible to overwrite annotations without language changes. However with Jukka's syntax it looks difficult. A possible pure-Python way could be to insert an item in an enclosing __annotations__, if an enclosing scope is a class or module scope. -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash randomization and deterministic bytecode
Thanks for the clarification. I'm glad we can keep hash randomization disabled during our builds. On Fri, May 12, 2017 at 5:22 PM, Guido van Rossum wrote: > Don't worry, the PYTHONHASHSEED setting does not get recorded in the > bytecode header and the generated bytecode (even if it sometimes differs in > trivial ways) is usable with all hash seed settings. > > --Guido > > On Fri, May 12, 2017 at 6:06 AM, Freddy Rietdijk > wrote: > >> Hi, >> >> On Nix we set PYTHONHASHSEED to 0 when building packages, disabling hash >> randomization. We do this to improve determinism of the builds because we >> store the bytecode next to the code. >> >> When one runs Python directly or via a script PYTHONHASHSEED is not set >> thus enabling hash randomization. Am I correct when I say that in this case >> Python still uses the reproducibly build bytecode and, because its now >> running with a random seed we wouldn't be vulnerable to >> http://www.ocert.org/advisories/ocert-2011-003.html ? Or would it also >> try to each time also recompile bytecode? >> >> Kind regards, >> >> Freddy >> >> >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% >> 40python.org >> >> > > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
