On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote:
Hello,
After debugging a crash on AppVeyor for a submitter's PR
(see https://github.com/python/cpython/pull/4611 ), I came to the
following diagnosis: converting the "atexit" module (which is a
built-in C extension) to PEP 489 multiphase initiali
On 13 Dec. 2017 12:53 pm, "Victor Stinner" wrote:
2017-12-13 0:24 GMT+01:00 Guido van Rossum :
> Considered disagreement is acceptable.
Sure, I'm fine with that ;-)
> Nick, congrats with PEP 565! Please update the PEP to mark it as approved
> with a link to this message as the resolution, and l
On 11 Dec. 2017 6:50 am, "INADA Naoki" wrote:
Except one typo I commented on Github,
I accept PEP 540.
Well done, Victor and Nick for PEP 540 and 538.
Python 3.7 will be most UTF-8 friendly Python 3 than ever.
And thank you for all of your work on reviewing them! The appropriate
trade-offs bet
Hi Xavier,
I looked at your scripts to build Android but I failed to use them.
Anyway, I'm not sure why these scripts have to be part of the CPython
git repository.
Technically, is there a reason to put it aside the source code and
Unix build scripts (configure/Makefile/setup)?
Your https://gith
Hi Eric,
Thanks for a detailed review!
On Wed, Dec 13, 2017 at 3:59 PM, Eric Snow wrote:
> Overall, I like this PEP. It's definitely easier to follow
> conceptually than PEP 550. Thanks for taking the time to re-think the
> idea. I have a few comments in-line below.
>
> -eric
>
> On Tue, Dec
On Tue, Dec 12, 2017 at 4:49 PM, Victor Stinner
wrote:
>> The ``Token`` API exists to make the current proposal forward
>> compatible with :pep:`550`, in case there is demand to support
>> context variables in generators and asynchronous generators in the
>> future.
>
> Cool. I like the idea of st
Overall, I like this PEP. It's definitely easier to follow
conceptually than PEP 550. Thanks for taking the time to re-think the
idea. I have a few comments in-line below.
-eric
On Tue, Dec 12, 2017 at 10:33 AM, Yury Selivanov
wrote:
> This is a new proposal to implement context storage in Py
Hello,
After debugging a crash on AppVeyor for a submitter's PR
(see https://github.com/python/cpython/pull/4611 ), I came to the
following diagnosis: converting the "atexit" module (which is a
built-in C extension) to PEP 489 multiphase initialization can lead to
its m_traverse function (and pre
05.12.17 01:21, MRAB пише:
I've finally come to a conclusion as to what the "correct" behaviour of
zero-width matches should be: """always return the first match, but
never a zero-width match that is joined to a previous zero-width match""".
If it's about to return a zero-width match that's jo
Hi Dima,
2017-12-13 7:39 GMT+01:00 Dima Tisnek :
> get()/set(value)/delete() methods: Python provides syntax sugar for
> these, let's use it.
> (dict: d["k"]/d["k] = value/del d["k"]; attrs: obj.k/obj.k = value/del
> obj.k; inheriting threading.Local)
I was trapped by Context which is described a
On Tue, Dec 12, 2017 at 10:39 PM, Dima Tisnek wrote:
> My 2c:
> TL;DR PEP specifies implementation in some detail, but doesn't show
> how proposed change can or should be used.
>
>
>
> get()/set(value)/delete() methods: Python provides syntax sugar for
> these, let's use it.
> (dict: d["k"]/d["k]
11 matches
Mail list logo
