On Tue, Sep 6, 2016 at 9:00 AM, Nick Coghlan wrote:
> On 6 September 2016 at 14:04, Guido van Rossum wrote:
>> I'm sorry, but we're not going to invent new syntax this late in the
>> game. The syntax proposed by the PEP has been on my mind ever since
>> PEP 484 with very minor variations; I first
On 6 September 2016 at 02:51, Ian Foote wrote:
> On 05/09/16 14:46, Nick Coghlan wrote:
>> That's not what the PEP proposes for uninitialised variables though:
>> it proposes processing them *before* a series of assignment
>> statements, which *only makes sense* if you plan to use them to
>> const
On 6 September 2016 at 14:04, Guido van Rossum wrote:
> I'm sorry, but we're not going to invent new syntax this late in the
> game. The syntax proposed by the PEP has been on my mind ever since
> PEP 484 with very minor variations; I first proposed it seriously on
> python-ideas over a month ago,
On 05/09/16 14:46, Nick Coghlan wrote:
> That's not what the PEP proposes for uninitialised variables though:
> it proposes processing them *before* a series of assignment
> statements, which *only makes sense* if you plan to use them to
> constrain those assignments in some way.
>
> If you wanted
I'm sorry, but we're not going to invent new syntax this late in the
game. The syntax proposed by the PEP has been on my mind ever since
PEP 484 with very minor variations; I first proposed it seriously on
python-ideas over a month ago, we've been debating the details since
then, and it's got a sol
On 6 September 2016 at 04:15, Guido van Rossum wrote:
> On Mon, Sep 5, 2016 at 10:24 AM, Ethan Furman wrote:
>> On 09/05/2016 06:46 AM, Nick Coghlan wrote:
>>
>> [an easy to understand explanation for those of us who aren't type-inferring
>> gurus]
>>
>> Thanks, Nick. I think I finally have a gr
On 5 September 2016 at 20:15, Guido van Rossum wrote:
> There are actually at least two separate cases: if x is a local
> variable, the intention of `x: ` is quite different from when x
> occurs in a class.
>
If I understand you correctly this also matches my mental model.
In local scope
x: ann
On 9/5/2016 11:34 AM, Guido van Rossum wrote:
On Mon, Sep 5, 2016 at 7:19 AM, Mark Shannon wrote:
Indeed, we shouldn't panic. We should take our time, review this carefully
and make sure that the version of typehints that lands in 3.7 is one that we
most of us are happy with and all of us can
On Mon, Sep 5, 2016 at 10:24 AM, Ethan Furman wrote:
> On 09/05/2016 06:46 AM, Nick Coghlan wrote:
>
> [an easy to understand explanation for those of us who aren't type-inferring
> gurus]
>
> Thanks, Nick. I think I finally have a grip on what Mark was talking about,
> and about how these things
On 09/05/2016 06:46 AM, Nick Coghlan wrote:
[an easy to understand explanation for those of us who aren't type-inferring
gurus]
Thanks, Nick. I think I finally have a grip on what Mark was talking about,
and about how these things should work.
Much appreciated!
--
~Ethan~
__
On Tue, Sep 6, 2016 at 2:17 AM, Steven D'Aprano wrote:
>> > The type comment systax is required for Python 2 and backwards-
>> > compatibility. That's a given.
>>
>> Sure, but all type checkers will not have to care about Python 2.
>
> They will have to care about type comments until such time as
On Mon, Sep 05, 2016 at 04:40:08PM +0300, Koos Zevenhoven wrote:
> On Mon, Sep 5, 2016 at 3:10 PM, Steven D'Aprano wrote:
> >
> > [Koos Zevenhoven]
> >> >> How is it going to help that these are equivalent within one checker,
> >> >> if the meaning may differ across checkers?
> >
> > Before I can
On Mon, Sep 5, 2016 at 7:19 AM, Mark Shannon wrote:
> On 04/09/16 21:16, Guido van Rossum wrote:
>>
>> Everybody please stop panicking. PEP 526 does not make a stand on the
>> behavior of type checkers (other than deferring to PEP 484). If you
>> want to start a discussion about constraining type
On Mon, Sep 5, 2016 at 5:02 PM, Nick Coghlan wrote:
> On 5 September 2016 at 23:46, Nick Coghlan wrote:
>> Under such "parameter annotation like" semantics, uninitialised
>> variable annotations would only make sense as a new form of
>> post-initialisation assertion,
Why not discuss this in the
On 04/09/16 21:16, Guido van Rossum wrote:
Everybody please stop panicking. PEP 526 does not make a stand on the
behavior of type checkers (other than deferring to PEP 484). If you
want to start a discussion about constraining type checkers please do
it over at python-ideas. There is no rush as
On 5 September 2016 at 23:46, Nick Coghlan wrote:
> Under such "parameter annotation like" semantics, uninitialised
> variable annotations would only make sense as a new form of
> post-initialisation assertion, and perhaps as some form of
> Eiffel-style class invariant documentation syntax.
Think
Sorry, I don't have time to read emails of this length now, and
perhaps I'm interpreting your emails more literally than you write
them, anyway.
If PEP 484 introduces unnecessary restrictions at this point, that's a
separate issue. I see no need to copy those into PEP 526. I'll be
posting my own r
On 5 September 2016 at 21:46, Koos Zevenhoven wrote:
> The thing I'm promoting here is to not add anything to PEP 526 that
> says what a type checker is supposed to do with type annotations.
PEP 526 says it doesn't intend to expand the scope of typechecking
semantics beyond what PEP 484 already s
It looks like you are trying to make sense of this, but unfortunately
there's some added mess and copy&paste-like errors regarding who said
what. I think no such errors remain in what I quote below:
On Mon, Sep 5, 2016 at 3:10 PM, Steven D'Aprano wrote:
>
> [Koos Zevenhoven]
>> >> How is it going
On Mon, Sep 05, 2016 at 11:19:38AM +0300, Koos Zevenhoven wrote:
> On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote:
[...]
> > On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
> >> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi
> >> wrote:
> >>> On 4 September 2016 at 19:59, Nick Coghlan
On Mon, Sep 5, 2016 at 1:04 PM, Nick Coghlan wrote:
> On 5 September 2016 at 18:19, Koos Zevenhoven wrote:
>> On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote:
>>> On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi
wrote:
> On
On 5 September 2016 at 18:19, Koos Zevenhoven wrote:
> On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote:
>> On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
>>> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi
>>> wrote:
On 4 September 2016 at 19:59, Nick Coghlan wrote:
>>> [...]
>>
On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote:
> On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
>> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi wrote:
>>> On 4 September 2016 at 19:59, Nick Coghlan wrote:
>> [...]
Similarly, it would be reasonable to say that these three
On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi wrote:
>> On 4 September 2016 at 19:59, Nick Coghlan wrote:
> [...]
>>>
>>> Similarly, it would be reasonable to say that these three snippets
>>> should all be equivalent from a typechecking p
On Sun, Sep 04, 2016 at 12:31:26PM +0100, Mark Shannon wrote:
As defined in PEP 526, I think that type
annotations become a hindrance to type inference.
In Haskell-like languages, type annotations have no
ability to influence whether types can be inferred.
The compiler infers a type for everyt
Everybody please stop panicking. PEP 526 does not make a stand on the
behavior of type checkers (other than deferring to PEP 484). If you
want to start a discussion about constraining type checkers please do
it over at python-ideas. There is no rush as type checkers are not
affected by the feature
On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi wrote:
> On 4 September 2016 at 19:59, Nick Coghlan wrote:
[...]
>>
>> Similarly, it would be reasonable to say that these three snippets
>> should all be equivalent from a typechecking perspective:
>>
>> x = None # type: Optional[T]
>>
>> x
On 5 September 2016 at 04:13, Ivan Levkivskyi wrote:
> On 4 September 2016 at 19:59, Nick Coghlan wrote:
>> I suspect you'll have an easier time of it on that front if you
>> include some examples of dynamically typed code that a well-behaved
>> type-checker *must* report as correct Python code,
On 4 September 2016 at 19:59, Nick Coghlan wrote:
Nick,
Thank you for good suggestions.
> I mostly agree, but the PEP still needs to address the fact that it's
> only a subset of the benefits that actually require new syntax, since
> it's that subset which provides the rationale for rejecting
On 5 September 2016 at 03:23, Ivan Levkivskyi wrote:
> On 4 September 2016 at 18:43, Nick Coghlan wrote:
>>
>> On 4 September 2016 at 21:32, Ivan Levkivskyi
>> wrote:
>> > The first form still could be interpreted by type checkers
>> > as annotation for value (a cast to more precise type):
>> >
On 4 September 2016 at 19:29, Nick Coghlan wrote:
> So in this case, attempting to entirely defer specification of the
> semantics creates a significant risk of type checkers written on the
> assumption of C++ or Java style type declarations actively inhibiting
> the dynamism of Python code, sugg
On 4 September 2016 at 21:51, Steven D'Aprano wrote:
> On Sun, Sep 04, 2016 at 12:31:26PM +0100, Mark Shannon wrote:
>
>> In other words PEP 484 specifically states that annotations are to help
>> with type inference. As defined in PEP 526, I think that type
>> annotations become a hindrance to ty
On 4 September 2016 at 18:43, Nick Coghlan wrote:
> On 4 September 2016 at 21:32, Ivan Levkivskyi
> wrote:
> > The first form still could be interpreted by type checkers
> > as annotation for value (a cast to more precise type):
> >
> > variable = cast(annotation, value) # visually also looks si
On Sun, Sep 4, 2016 at 7:43 PM, Nick Coghlan wrote:
> On 4 September 2016 at 21:32, Ivan Levkivskyi wrote:
>> The first form still could be interpreted by type checkers
>> as annotation for value (a cast to more precise type):
>>
>> variable = cast(annotation, value) # visually also looks similar
On 4 September 2016 at 21:32, Ivan Levkivskyi wrote:
> The first form still could be interpreted by type checkers
> as annotation for value (a cast to more precise type):
>
> variable = cast(annotation, value) # visually also looks similar
I think a function based spelling needs to be discussed f
On Sun, Sep 4, 2016 at 3:43 PM, Steven D'Aprano wrote:
[...]
> [steve@ando ~]$ cat test.py
> from typing import Optional
>
> def foo(x:Optional[int])->int:
> if x is None:
> return -1
> return x + 1
>
> def bar(x:Optional[int])->int:
> y = x # the type of y must be inferred
>
On 4 September 2016 at 15:07, Steven D'Aprano wrote:
> > PEP 526
> > variable: annotation = value
> >
> > Which reads very much as if the annotation refers to the variable.
>
> Since the PEP makes it clear that the two forms are to be treated the
> same, I think that whatever difference you think
Referring to the alternative syntax forms:
# Proposed
x: int = func(value)
# Already accepted
x = func(value) #type: int
On Sun, Sep 04, 2016 at 11:52:24AM +0100, Mark Shannon wrote:
> The key difference is in placement.
> PEP 484 style
> variable = value # annotation
>
> Whi
On Sun, Sep 04, 2016 at 12:30:18PM +0100, Mark Shannon wrote:
> It would be a real shame if PEP 526 mandates against checkers doing as
> good as job as possible. Forcing all uses of a variable to have the same
> type is a major and, IMO crippling, limitation.
This is approaching FUD.
Guido has
On Sun, Sep 4, 2016 at 1:52 PM, Mark Shannon wrote:
[...]
>
> The key difference is in placement.
> PEP 484 style
> variable = value # annotation
>
> Which reads to me as if the annotation refers to the value.
> PEP 526
> variable: annotation = value
>
> Which reads very much as if the annotation
On 4 September 2016 at 13:30, Mark Shannon wrote:
> It would be a real shame if PEP 526 mandates against checkers doing as
> good as job as possible. Forcing all uses of a variable to have the same
> type is a major and, IMO crippling, limitation.
>
> E.g.
> def foo(x:Optional[int])->int:
> i
On Sun, Sep 04, 2016 at 12:31:26PM +0100, Mark Shannon wrote:
> In other words PEP 484 specifically states that annotations are to help
> with type inference. As defined in PEP 526, I think that type
> annotations become a hindrance to type inference.
I'm pretty sure that they don't.
Have you
On 04/09/16 11:57, Chris Angelico wrote:
On Sun, Sep 4, 2016 at 8:52 PM, Mark Shannon wrote:
The key difference is in placement.
PEP 484 style
variable = value # annotation
Which reads to me as if the annotation refers to the value.
PEP 526
variable: annotation = value
Which reads very much
On 4 September 2016 at 12:52, Mark Shannon wrote:
> The key difference is in placement.
> PEP 484 style
> variable = value # annotation
>
> Which reads to me as if the annotation refers to the value.
> PEP 526
> variable: annotation = value
>
> Which reads very much as if the annotation refers to
On 02/09/16 20:33, Guido van Rossum wrote:
On Fri, Sep 2, 2016 at 10:47 AM, Steve Dower wrote:
"I'm not seeing what distinction you think you are making here. What
distinction do you see between:
x: int = func(value)
and
x = func(value) # type: int"
Not sure whether I agree with
On Sun, Sep 4, 2016 at 8:52 PM, Mark Shannon wrote:
> The key difference is in placement.
> PEP 484 style
> variable = value # annotation
>
> Which reads to me as if the annotation refers to the value.
> PEP 526
> variable: annotation = value
>
> Which reads very much as if the annotation refers t
On 02/09/16 19:19, Steven D'Aprano wrote:
On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote:
"I'm not seeing what distinction you think you are making here. What
distinction do you see between:
x: int = func(value)
and
x = func(value) #type: int"
Not sure whether I agree w
On 02/09/16 19:04, Steven D'Aprano wrote:
On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote:
A good checker should be able to infer that x is a union type at the
point that it's passed to spam, even without the type annotation. For
example:
def eggs(cond:bool):
if cond:
On Fri, Sep 2, 2016 at 10:47 AM, Steve Dower wrote:
> "I'm not seeing what distinction you think you are making here. What
> distinction do you see between:
>
> x: int = func(value)
>
> and
>
> x = func(value) # type: int"
>
> Not sure whether I agree with Mark on this particular point, b
[Replying to Steve Dower]
On Sat, Sep 03, 2016 at 04:19:13AM +1000, Steven D'Aprano wrote:
> On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote:
> > "I'm not seeing what distinction you think you are making here. What
> > distinction do you see between:
> >
> > x: int = func(value)
On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote:
> "I'm not seeing what distinction you think you are making here. What
> distinction do you see between:
>
> x: int = func(value)
>
> and
>
> x = func(value) #type: int"
>
> Not sure whether I agree with Mark on this particu
On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote:
> A good checker should be able to infer that x is a union type at the
> point that it's passed to spam, even without the type annotation. For
> example:
>
> def eggs(cond:bool):
> if cond:
> x = 1
> else:
>
On 2 September 2016 at 17:59, Guido van Rossum wrote:
> On Fri, Sep 2, 2016 at 6:47 AM, Mark Shannon wrote:
> > Quoting from the PEP:
> > ```
> > a: int
> > a: str # Static type checker will warn about this.
> > ```
> > In other words, it is illegal for a checker to split up the variable,
even
>
e sure that it's the direction we want the language to go.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Steven D'Aprano"
Sent: 9/2/2016 9:43
To: "python-dev@python.org"
Subject: Re: [Python-Dev] Please reject or postpone PEP 526
I agree about some concerns and disagree about several. I see most use
for class/instance attribute annotations, both for type checking and
for other uses. I'm least sure about their syntax and about
annotations in functions or at module level in the proposed form.
Below some comments:
On Fri, Se
Hi Mark,
I agree with you about postponing.
Not so much because of the issues you mentioned. Those all seem
resolvable to me and mostly concerns type checkers, linters and coding
styles not Python itself. However, I also don't like the rushing through
as if this beta were the only chance to g
Hi Mark,
I'm going to trim your post drastically, down to the bare essentials, in
order to keep this already long post down to a manageable size.
On Fri, Sep 02, 2016 at 02:47:00PM +0100, Mark Shannon wrote:
[...]
> With type comments, this is intuitively correct and should type check:
> def e
On Fri, Sep 2, 2016 at 6:47 AM, Mark Shannon wrote:
> Hi everyone,
>
> I think we should reject, or at least postpone PEP 526.
>
> PEP 526 represents a major change to the language, however there are, I
> believe, a number of technical flaws with the PEP.
>
> It is probable that with significant r
On Sep 2, 2016 8:51 AM, "Mark Shannon" wrote:
>
> Hi everyone,
>
> I think we should reject, or at least postpone PEP 526.
>
> PEP 526 represents a major change to the language, however there are, I
believe, a number of technical flaws with the PEP.
>
> It is probable that with significant revisio
59 matches
Mail list logo
