Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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] >> >>

Re: [Python-Dev] Where are the list and array.array implementations in CPython source?

On Mon, Sep 5, 2016 at 8:10 PM, Martin Panter wrote: > Built-in objects are usually in the Objects/ directory, with a > corresponding include file in the Include/ directory: > https://hg.python.org/cpython/file/default/Objects/listobject.c >

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On Mon, Sep 5, 2016 at 9:45 PM, Steve Dower wrote: > > So it works, though the behaviour is a little strange when you do it from > the interactive prompt: > sys.stdin.buffer.raw.read(1) > ɒprint('hi') > b'\xc9' hi sys.stdin.buffer.raw.read(1) > b'\x92'

Re: [Python-Dev] Where are the list and array.array implementations in CPython source?

Include/listobject.h Objects/listobject.c Modules/arraymodule.c On Mon, Sep 5, 2016, at 16:45, Jonathan Goble wrote: > I'd like to study the CPython implementations of lists and array.array > instances for a personal project of mine, but I've very unfamiliar > with the Python source code as it

Re: [Python-Dev] Where are the list and array.array implementations in CPython source?

On 5 September 2016 at 23:45, Jonathan Goble wrote: > I'd like to study the CPython implementations of lists and array.array > instances for a personal project of mine, but I've very unfamiliar > with the Python source code as it pertains to internals like this. > Which files

[Python-Dev] Where are the list and array.array implementations in CPython source?

I'd like to study the CPython implementations of lists and array.array instances for a personal project of mine, but I've very unfamiliar with the Python source code as it pertains to internals like this. Which files would I need to look at to do this, and are there a few particular

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On Tue, Sep 6, 2016 at 1:49 AM, Sven R. Kunze wrote: > Didn't Koos say this works more like an expression annotation? > > IMO, the type of the expression is what is specified but the type of the > variable can change over time (as you demonstrated). That's exactly the kind of

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Didn't Koos say this works more like an expression annotation? IMO, the type of the expression is what is specified but the type of the variable can change over time (as you demonstrated). Sven PS: thinking this way, the new syntax is actually confusing as it annotates the variable not the

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

I would take the opposite approach from Greg Ewing, namely that the annotation is not a permission of values but a starting point for the type inferencer; and the type checker/inferencer can complain if there's an inconsistency (for some definition of "inconsistency", which is not defined in the

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Mark Shannon wrote: Unless of course, others may have a different idea of what the "type of a variable" means. To me, it means it means that for all assignments `var = expr` the type of `expr` must be a subtype of the variable, and for all uses of var, the type of the use is the same as the

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 05Sep2016 1308, Paul Moore wrote: On 5 September 2016 at 20:30, Steve Dower wrote: The only case we can reasonably handle at the raw layer is "n / 4" is zero but n != 0, in which case we can read and cache up to 4 bytes (one wchar_t) and then return those in future

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On Mon, Sep 5, 2016 at 7:54 PM, Steve Dower wrote: > On 05Sep2016 1234, eryk sun wrote: >> >> Also, the console is UCS-2, which can't be transcoded between UTF-16 >> and UTF-8. Supporting UCS-2 in the console would integrate nicely with >> the filesystem PEP. It makes it

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 20:34, eryk sun wrote: > Paul, do you have example code that uses the 'raw' stream? Using the > buffer should behave as it always has -- at least in this regard. > sys.stdin.buffer requests a large block, such as 8 KB. But since the > console defaults to

Re: [Python-Dev] TLS handshake performance boost

On 9/5/16 12:57, Christian Heimes wrote: > I have yet another patch for the ssl module, > http://bugs.python.org/issue19500 . The patch adds support for SSL > session resumption on the client side. [...] > > My patch takes care of these details. The basic features are pretty much > done and

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 20:30, Steve Dower wrote: > The only case we can reasonably handle at the raw layer is "n / 4" is zero > but n != 0, in which case we can read and cache up to 4 bytes (one wchar_t) > and then return those in future calls. If we try to cache any more

[Python-Dev] TLS handshake performance boost

Hi, I have yet another patch for the ssl module, http://bugs.python.org/issue19500 . The patch adds support for SSL session resumption on the client side. A SSLContext automatically handles server-side session. SSL sessions speed up successive TLS connections to the same host considerable. My

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 05Sep2016 1234, eryk sun wrote: Also, the console is UCS-2, which can't be transcoded between UTF-16 and UTF-8. Supporting UCS-2 in the console would integrate nicely with the filesystem PEP. It makes it always possible to print os.listdir('.'), copy and paste, and read it back without data

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

I have some suggestions. With ReadConsoleW, CPython can use the pInputControl parameter to set a CtrlWakeup mask. This enables a Unix-style Ctrl+D for ending a read without having to press enter. For example: >>> CTRL_MASK = 1 << 4 >>> inctrl = (ctypes.c_ulong * 4)(16, 0, CTRL_MASK, 0)

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 05Sep2016 1110, Paul Moore wrote: On 5 September 2016 at 18:38, Steve Dower wrote: Can you provide an example of how I'd rewrite the code that I quoted previously to follow this advice? Note - this is not theoretical, I expect to have to provide a PR to fix exactly

Re: [Python-Dev] Push PEP 528 (use utf8 on Windows) right now, but revert before 3.6 if needed

On 9/5/16 11:44, Victor Stinner wrote: > I just spoke with Steve Dower (thanks for the current sprint!) about > the PEP 528. We somehow agreed that we need to push his implementation > of the PEP right now to get enough time to test as much applications > as possible on Windows to have a wide view

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

[Python-Dev] Push PEP 528 (use utf8 on Windows) right now, but revert before 3.6 if needed

Hi, I just spoke with Steve Dower (thanks for the current sprint!) about the PEP 528. We somehow agreed that we need to push his implementation of the PEP right now to get enough time to test as much applications as possible on Windows to have a wide view of possible all regressions. The hope is

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 18:38, Steve Dower wrote: >> Can you provide an example of how I'd rewrite the code that I quoted >> previously to follow this advice? Note - this is not theoretical, I >> expect to have to provide a PR to fix exactly this code should this >> change

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On Mon, Sep 05, 2016 at 04:26:17PM +0100, Mark Shannon wrote: > In this example: > > def bar()->Optional[int]: ... > > def foo()->int: > x:Optional[int] = bar() > if x is None: > return -1 > return x > > According to PEP 526 the annotation

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On Mon, Sep 5, 2016 at 8:26 AM, Mark Shannon wrote: > PEP 526 states that "This PEP aims at adding syntax to Python for annotating > the types of variables" and Guido seems quite insistent that the > declarations are for the types of variables. > > However, I get the impression

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 05Sep2016 0941, Paul Moore wrote: On 5 September 2016 at 14:36, Steve Dower wrote: The best fix is to use a buffered reader, which will read all the available bytes and then let you .read(1), even if it happens to be an incomplete character. But this is

Re: [Python-Dev] Please reject or postpone PEP 526

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~

Re: [Python-Dev] PEP 467: last round (?)

On 09/03/2016 09:48 AM, Nick Coghlan wrote: On 3 September 2016 at 21:35, Martin Panter wrote: On 3 September 2016 at 08:47, Victor Stinner wrote: Le samedi 3 septembre 2016, Random832 a écrit : On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: The problem with only having `bchr` is that

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 14:36, Steve Dower wrote: > The best fix is to use a buffered reader, which will read all the available > bytes and then let you .read(1), even if it happens to be an incomplete > character. But this is sys.stdin.buffer.raw, we're talking about.

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Maybe the PEP should just say it's for "annotating variables", and it would mention "primarily for the purpose of types"? -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Sep 5, 2016 10:27 AM, "Mark Shannon"

Re: [Python-Dev] Please reject or postpone PEP 526

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

[Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Hi, PEP 526 states that "This PEP aims at adding syntax to Python for annotating the types of variables" and Guido seems quite insistent that the declarations are for the types of variables. However, I get the impression that most (all) of the authors and proponents of PEP 526 are quite

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

It looks like you are trying to make sense of this, but unfortunately there's some added mess and copy 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

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

The best fix is to use a buffered reader, which will read all the available bytes and then let you .read(1), even if it happens to be an incomplete character. We could theoretically add buffering to the raw reader to handle one character, which would allow very small reads from raw, but that

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 10:37, Martin Panter wrote: > On 5 September 2016 at 09:10, Paul Moore wrote: >> On 5 September 2016 at 06:54, Steve Dower wrote: >>> +Using the raw object with small buffers >>>

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 09:10, Paul Moore wrote: > On 5 September 2016 at 06:54, Steve Dower wrote: >> +Using the raw object with small buffers >> +--- >> + >> +Code that uses the raw IO object and attempts to read

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 5 September 2016 at 06:54, Steve Dower wrote: > +Using the raw object with small buffers > +--- > + > +Code that uses the raw IO object and attempts to read less than four > characters > +will now receive an error. Because it's

Re: [Python-Dev] Please reject or postpone PEP 526

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

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On 5 September 2016 at 15:59, Steve Dower wrote: > +continue to default to ``locale.getpreferredencoding()`` (for text files) or > +plain bytes (for binary files). This only affects the encoding used when > users > +pass a bytes object to Python where it is then passed to

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

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