I posted an update to PEP 529 at
https://github.com/python/peps/blob/master/pep-0529.txt and a diff below. The
update includes more detail on the affected code within CPython - including a
number of references to broken code that would be resolved with the change -
and more details about the ne
I posted a minor update to PEP 528 at
https://github.com/python/peps/blob/master/pep-0528.txt and a diff below.
While there are likely to be technical and compatibility issues to
resolve after the changes are applied, I don't believe they impact the
decision to accept the change at the PEP-lev
On 5 September 2016 at 06:42, Koos Zevenhoven wrote:
> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>>
>> There are two self-consistent sets of names:
>>
>
> Let me add a few. I wonder if this is really used so much that
> bytes.chr is too long to type (and you can do bchr = bytes.chr if y
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 4, 2016, at 16:42, Koos Zevenhoven wrote:
> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
> >
> > There are two self-consistent sets of names:
> >
>
> Let me add a few. I wonder if this is really used so much that
> bytes.chr is too long to type (and you can do bchr = bytes.chr
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
On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>
> There are two self-consistent sets of names:
>
Let me add a few. I wonder if this is really used so much that
bytes.chr is too long to type (and you can do bchr = bytes.chr if you
want to):
bytes.chr (or bchr in builtins)
bytes.chr_at, byte
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 4 September 2016 at 20:57, Christian Heimes wrote:
> On 2016-09-01 23:15, Victor Stinner wrote:
>> 2016-08-31 22:31 GMT+02:00 Christian Heimes :
>>> https://bugs.python.org/issue27744
>>> Add AF_ALG (Linux Kernel crypto) to socket module
>>
>> This patch adds a new socket.sendmsg_afalg() method
On 4 September 2016 at 20:43, Koos Zevenhoven wrote:
> On Sun, Sep 4, 2016 at 12:51 PM, Nick Coghlan wrote:
>> That said, the PEP does propose "getbyte()" and "iterbytes()" for
>> bytes-oriented indexing and iteration, so there's a reasonable
>> consistency argument in favour of also proposing "b
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 2016-09-01 23:15, Victor Stinner wrote:
> 2016-08-31 22:31 GMT+02:00 Christian Heimes :
>> https://bugs.python.org/issue27744
>> Add AF_ALG (Linux Kernel crypto) to socket module
>
> This patch adds a new socket.sendmsg_afalg() method on Linux.
>
> "afalg" comes from AF_ALG which means "Addres
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 Sun, Sep 4, 2016 at 12:51 PM, Nick Coghlan wrote:
> On 4 September 2016 at 08:11, Random832 wrote:
>> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote:
>>> I guess one reason I don't like bchr (nor chrb, really) is that they
>>> look just like a random sequence of letters in builtins, but
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 4 September 2016 at 08:11, Random832 wrote:
> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote:
>> I guess one reason I don't like bchr (nor chrb, really) is that they
>> look just like a random sequence of letters in builtins, but not
>> recognizable the way asdf would be.
>>
>> I guess I
35 matches
Mail list logo
