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 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
> https://hg.python.org/cpython/file/default/Include/listo
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'
>
> What happens here is
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 per
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 would I need to look
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 functions/struc
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 semantics I'm descri
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
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 PE
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 typ
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 calls. If we try to cache
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 always possible to print
>
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 a cooked mode (i.e.
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 tested
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 than that
> we're substit
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 naïv
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 lo
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)
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 this code should this
chan
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
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
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
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 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 go in. At the moment I ca
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 `x:Optional[
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 that most (all) of
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 sys.stdin.buffer.raw, we're talking
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 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 i
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. People can't
really layer an
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
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" w
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
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 keen
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 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
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 se
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 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
>>> +---
>>> +
>>> +Code that uses the raw IO object and attem
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 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 less than four
>> characters
>> +will now rece
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 possible that any single chara
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 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 the operating
> system
54 matches
Mail list logo
