On Fri, Jun 2, 2017 at 1:07 PM, Koos Zevenhoven wrote:
> [...]
> I suppose it is, especially because there seems to be nothing that
> prevents you from getting runtime annotations in the enclosing class/module
> :
>
>
> number: int
>
> @call
> def number():
> return 42
>
Well mypy actually
On Fri, Jun 2, 2017 at 8:57 PM, Guido van Rossum wrote:
> On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven wrote:
>>
>> 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__ attr
On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven wrote:
> On Fri, Jun 2, 2017 at 6:34 PM, Naomi Seyfer 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 anythin
On Fri, Jun 2, 2017 at 6:34 PM, Naomi Seyfer 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 happ
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 Le
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
>
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
> On 15 May 2017 at 10:48, Koos Zevenhoven wrote:
>
>> 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.
>>
>
It took me a while to re
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
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
>
On Tue, May 09, 2017 at 11:54:26PM +0400, Abdur-Rahmaan Janhangeer wrote:
> I'm really new to the mailing list. Can someone just summarise the
> preceding message in 5 to 10 lines like what it is, what type is it or when
> does it happen
It is an update to PEP 484, adding support for type-checking
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.
Readabi
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 de
Stay tuned for the pep that allows callable to take keyword args.
> On May 9, 2017, at 3:59 PM, Brett Cannon 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 w
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
I'm really new to the mailing list. Can someone just summarise the
preceding message in 5 to 10 lines like what it is, what type is it or when
does it happen
Thanks for all,
Abdur-Rahmaan Janhangeer
Vacoas,
Mauritius
https://abdurrahmaanjanhangeer.wordpress.com/
__
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), i
17 matches
Mail list logo