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

[Naomi Seyfer]

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.

On Wed, May 31, 2017 at 3:17 PM, Guido van Rossum  wrote:

> On Wed, May 31, 2017 at 6:16 AM, Ivan Levkivskyi 
> wrote:
>
>> On 30 May 2017 at 23:02, Guido van Rossum  wrote:
>>
>>> All in all I'm still leaning towards Naomi's original proposal -- it
>>> looks simpler to implement as well.
>>>
>>
>> OK, I think having a bit of verbosity is absolutely fine if we win
>> simplicity of implementation (for both static and runtime purposes).
>>
>
> Then I propose to do it this way. We can always add Jukka's way as an
> alternative notation later. I'd like to hear from Jukka before I merge the
> PR for PEP-484.
>
> In the meantime, Naomi, are you interested in trying to implement this?
>
> --
> --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

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

[Naomi Seyfer]

I think you're right that the redefinition style is easier to read for 
complicated stuff... It also seems more complicated in a way I can't put my 
finger on. 

The overload precedent helps. 

Currently leaning towards Jukka being right, vague worries about extra 
complication be damned. 

Readability is more important. 

> On May 10, 2017, at 5:23 AM, Jukka Lehtosalo <jlehtos...@gmail.com> wrote:
> 
> Even if Callable types will soon support keyword arguments, the syntax for 
> Callables will look quite different from function definitions and this 
> inconsistency may hurt readability, at least for more complex signatures. We 
> could work around this by using the def syntax for the declared type of a 
> decorator. For example:
> 
> @declared_type
> def session(url: str) -> ContextManager[DatabaseSession]: ...  # Explicit 
> '...'
> 
> @contextmanager
> def session(url: str) -> Iterator[DatabaseSession]:
> s = DatabaseSession(url)
> ...
> 
> This would be quite similar to how overloads work, so there is a precedent 
> for something like this. We could require or recommend that the declared type 
> comes immediately before the implementation so that the entire definition of 
> a single function would not be too spread out.
> 
> This won't help if the decorated type is not a callable. We could support 
> this use case by using the normal variable annotation syntax:
> 
> thing: Decorated  # Declared type of 'thing'
> 
> @decorator
> def thing() -> int:
> ...
> 
> Jukka
> 
>> On Wed, May 10, 2017 at 12:27 AM, Naomi Seyfer <na...@seyfer.org> wrote:
>> Stay tuned for the pep that allows callable to take keyword args. 
>> 
>>> On May 9, 2017, at 3:59 PM, Brett Cannon <br...@python.org> wrote:
>>> 
>>> The idea seems reasonable to me when viewing type hints as a form of 
>>> documentation as it helps remind people how they are expected to call the 
>>> final function.
>>> 
>>> One worry I do have, though, is Callable doesn't support keyword-only 
>>> parameters, so declared_type won't work in all cases without Callable 
>>> gaining such support (for those that don't know, Callable didn't start with 
>>> that support as Callable has been meant for callback scenarios up to this 
>>> point).
>>> 
>>>> On Tue, 9 May 2017 at 10:21 Guido van Rossum <gu...@python.org> 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).
>>>> 
>>>> 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[DatabaseS

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

[Naomi Seyfer]

Stay tuned for the pep that allows callable to take keyword args. 

> On May 9, 2017, at 3:59 PM, Brett Cannon <br...@python.org> wrote:
> 
> The idea seems reasonable to me when viewing type hints as a form of 
> documentation as it helps remind people how they are expected to call the 
> final function.
> 
> One worry I do have, though, is Callable doesn't support keyword-only 
> parameters, so declared_type won't work in all cases without Callable gaining 
> such support (for those that don't know, Callable didn't start with that 
> support as Callable has been meant for callback scenarios up to this point).
> 
>> On Tue, 9 May 2017 at 10:21 Guido van Rossum <gu...@python.org> 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).
>> 
>> 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``.
>> +
>> 
>> -- 
>> --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/brett%40python.org
___
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