Hi,
first if something like this is needed I am fine with the syntax.
But I think this changes comes to late for 3.6. There is more time needed
to discuss all of this and there is more time needed to mature the type
checkers. Don't rush with such a change because it affects the language at
whole
Hi,
first if something like this is needed I am fine with the syntax.
But I think this changes comes to late for 3.6. There is more time needed
to discuss all of this and there is more time needed to mature the type
checkers. Don't rush with such a change because it affects the language at
whole
On 2016-08-30 2:20 PM, Guido van Rossum wrote:
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)
There's also an implementation ready:
https://github.com/ilevkivskyi/cpython
On 3 September 2016 at 02:17, Guido van Rossum wrote:
> Pinning down the semantics is not why I am pushing for PEP 526 -- I
> only want to pin down the *syntax* to the point where we won't have to
> change it again for many versions, since it's much harder to change
> the syntax than it is to chan
On 2 September 2016 at 18:17, Guido van Rossum wrote:
> On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi
wrote:
> > On 2 September 2016 at 04:38, Nick Coghlan wrote:
> >> However, a standalone Ellipsis doesn't currently have a meaning as a
> >> type annotation (it's only meaningful when subscript
On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi wrote:
> On 2 September 2016 at 04:38, Nick Coghlan wrote:
>> However, a standalone Ellipsis doesn't currently have a meaning as a
>> type annotation (it's only meaningful when subscripting Tuple and
>> Callable), so a spelling like this might work:
On 1 September 2016 at 22:37, Guido van Rossum wrote:
> On Thu, Sep 1, 2016 at 9:30 AM, Ivan Levkivskyi
wrote:
> > There is a convention for function annotations in PEP 484 that a missing
> > annotation is equivalent to Any, so that I like your first option more.
>
> But Steven wasn't proposing i
On 2 September 2016 at 02:21, Steven D'Aprano wrote:
> Unless I've missed something, there's no way to pre-declare an instance
> attribute without specifying a type. (Even if that type is Any.) So how
> about we allow None as a type-hint on its own:
>
> NAME: None
None already has a meaning a
On Thu, Sep 1, 2016 at 9:30 AM, Ivan Levkivskyi wrote:
> On 1 September 2016 at 18:21, Steven D'Aprano wrote:
[...]
>> Unless I've missed something, there's no way to pre-declare an instance
>> attribute without specifying a type. (Even if that type is Any.) So how
>> about we allow None as a typ
On Thu, Sep 1, 2016 at 10:01 AM, Koos Zevenhoven wrote:
> On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum wrote:
>> IOW, PEP 3157 is not dead yet. Indeed.
>>
>
> PEP 3157? Is that a typo or is there such a thing somewhere?
Sorry, 3107 (the original Function Annotations PEP).
> [...]
> I hope t
On Thu, Sep 1, 2016 at 10:30 AM, Steven D'Aprano wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>
>> - Whether (given PEP 484's relative success) it's worth adding syntax
>> for variable/attribute annotations.
>
> The PEP makes a good case that it does.
Thanks, I agree
On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> - Whether (given PEP 484's relative success) it's worth adding syntax
> for variable/attribute annotations.
The PEP makes a good case that it does.
> - Whether the keyword-free syntax idea proposed here is best:
> NAME: TYPE
On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum wrote:
> On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven wrote:
>> While a large amount of Python programmers may not be interested in
>> type hinting local variables inside functions, I can see other
>> potential benefits in this.
>
> IOW, PEP 315
On 1 September 2016 at 18:21, Steven D'Aprano wrote:
> The simplest way would be to say "go on, one type hint won't hurt,
> there's no meaningful runtime cost, just do it".
>
> from typing import Any
>
> class X:
> NAME: Any
>
> Since I'm not running a type checker, it doesn't matter what hin
On Thu, Sep 01, 2016 at 04:11:05PM +0300, Koos Zevenhoven wrote:
> Maybe it's just me, but I've always thought 'def' is Python's least
> logically used keyword. It seems to come from 'define', but what is it
> about 'define' that makes it relate to functions only.
Convention.
You can't use "def"
On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven wrote:
> While a large amount of Python programmers may not be interested in
> type hinting local variables inside functions, I can see other
> potential benefits in this.
IOW, PEP 3157 is not dead yet. Indeed.
> When I start sketching a new class,
On Wed, Aug 31, 2016 at 12:20 AM, Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
>
> There's also an implementation ready:
> https://github.com/
On 31 August 2016 at 13:09, Nick Coghlan wrote:
> I guess as long as they're included somewhere in the AST for the
> function body, I don't mind if the translation to bytecode throws them
> away - that's essentially saying that a function level type annotation
> is effectively interpreted as if i
On Tue, Aug 30, 2016 at 07:15:55PM -0700, Guido van Rossum wrote:
> On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote:
> > On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> >> I'm happy to present PEP 526 for your collective review:
> >
> > Are you hoping to get this in befo
On 31 August 2016 at 15:40, Guido van Rossum wrote:
> On Tuesday, August 30, 2016, Nick Coghlan wrote:
>> What if we included local variable annotations in func.__annotations__
>> as cells, like the entries in func.__closure__?
>>
>> We could also use that as a micro-optimisation technique: once
On Tuesday, August 30, 2016, Nick Coghlan wrote:
> On 31 August 2016 at 13:37, Jack Diederich > wrote:
> > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum > wrote:
> >> But myfunc.__annotations__ already exists -- PEP 3107 puts the
> >> signature annotations there. The problem with co_annota
On 31 August 2016 at 13:37, Jack Diederich wrote:
> On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum wrote:
>> But myfunc.__annotations__ already exists -- PEP 3107 puts the
>> signature annotations there. The problem with co_annotations is that
>> annotations are evaluated (they can be quite c
On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum wrote:
> On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich
> wrote:
> > +0. We should try and be consistent even if this is a thing I don't want.
> > And trust me, I don't!
>
> No problem. You won't have to!
>
>
Yes! I don't have to want it, it is
On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich wrote:
> +0. We should try and be consistent even if this is a thing I don't want.
> And trust me, I don't!
No problem. You won't have to!
> That said, as long as pro-mypy people are willing to make everyone else pay
> a mypy reading tax for code l
+0. We should try and be consistent even if this is a thing I don't
want. And trust me, I don't!
That said, as long as pro-mypy people are willing to make everyone else pay
a mypy reading tax for code let's try and reduce the cognitive burden.
* Duplicate type annotations should be a syntax error
On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>> I'm happy to present PEP 526 for your collective review:
>
> Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> can give this much attention before th
On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
Are you hoping to get this in before 3.6 beta? Because I'm not sure I
can give this much attention before then, but I really want to.
--
Steve
__
On Tue, 30 Aug 2016 at 14:21 Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
>
> There's also an implementation ready:
> https://github.com/ilev
Thanks Guido, also to the rest of the PEP team (4 people) :)
On 30.08.2016 23:20, Guido van Rossum wrote:
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)
There's also an i
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)
There's also an implementation ready:
https://github.com/ilevkivskyi/cpython/tree/pep-526
I don't want to post the full text h
30 matches
Mail list logo
