Re: [Python-Dev] Inplace operations for PyLong objects

On Thu, 31 Aug 2017 23:35:34 + "Manciu, Catalin Gabriel" wrote: > > The focus of this experiment was inplace adds in general. While, as you've > shown, there are ways to write the loop optimally, the benchmark was written > as a huge loop just to showcase

Re: [Python-Dev] Inplace operations for PyLong objects

On Fri, Sep 1, 2017 at 9:35 AM, Manciu, Catalin Gabriel wrote: > A huge Python program with lots of PyLong inplace operations (not just > adds, this can be applied to all PyLong inplace operations), regardless of > them > being in a loop or not, might benefit

Re: [Python-Dev] Inplace operations for PyLong objects

>On my machine, the more realistic code, with an implicit C loop, >the_value = sum(the_increment for i in range(total_iters)) >gives the same value twice as fast as your explicit Python loop. >(I cut total_iters down to 10**7). Your code is faster due to a number of reasons: - range in Python

Re: [Python-Dev] bpo-5001: More-informative multiprocessing error messages (#3079)

On 8/31/2017 3:27 PM, Brett Cannon wrote: On Wed, 30 Aug 2017 at 02:56 Paul Moore

Re: [Python-Dev] Inplace operations for PyLong objects

On 8/31/2017 2:40 PM, Manciu, Catalin Gabriel wrote: Hi everyone, While looking over the PyLong source code in Objects/longobject.c I came across the fact that the PyLong object doesnt't include implementation for basic inplace operations such as adding or multiplication: [...] long_long,

Re: [Python-Dev] bpo-5001: More-informative multiprocessing error messages (#3079)

On 31 August 2017 at 20:27, Brett Cannon wrote: > So you would want a comment when the PR reaches "awaiting merge" with > instructions requesting the author do their own squash commit to simplify > the message for us? That would work. It could say that the PR consists of

Re: [Python-Dev] bpo-5001: More-informative multiprocessing error messages (#3079)

On Wed, 30 Aug 2017 at 02:56 Paul Moore wrote: > On 30 August 2017 at 10:48, Nick Coghlan wrote: > > On 30 August 2017 at 19:39, Antoine Pitrou wrote: > >> On Wed, 30 Aug 2017 08:48:56 +0300 > >> Serhiy Storchaka

[Python-Dev] Inplace operations for PyLong objects

Hi everyone, While looking over the PyLong source code in Objects/longobject.c I came across the fact that the PyLong object doesnt't include implementation for basic inplace operations such as adding or multiplication: [...] long_long, /*nb_int*/ 0,

Re: [Python-Dev] PEP 550 v4

On Wed, Aug 30, 2017 at 5:36 PM, Yury Selivanov wrote: > On Wed, Aug 30, 2017 at 9:44 AM, Yury Selivanov > wrote: > [..] > >> FYI, I've been sketching an alternative solution that addresses these > kinds > >> of things. I've been hesitant to

Re: [Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython

Because I couldn't go to there by myself, I'm really grateful to you and your first draft. Masayuki 2017-08-31 19:40 GMT+09:00 Erik Bray : > On Thu, Aug 31, 2017 at 10:16 AM, Masayuki YAMAMOTO > wrote: > > Hi python-dev, > > > > Since Erik

Re: [Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython

2017-08-31 18:51 GMT+09:00 Nick Coghlan : > [...] > I think that's just a bug in the startup refactoring - we don't > currently test the "Py_Initialize()/Py_Initialize()/Py_Finalize()" > sequence anywhere, and I'd missed that it's explicitly documented as > being permitted.

Re: [Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython

On Thu, Aug 31, 2017 at 10:16 AM, Masayuki YAMAMOTO wrote: > Hi python-dev, > > Since Erik started the PEP 539 thread on python-ideas, I've collected > feedbacks in the discussion and pull-request, and tried improvement for the > API specification and reference

Re: [Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython

On 31 August 2017 at 18:16, Masayuki YAMAMOTO wrote: > Hi python-dev, > > Since Erik started the PEP 539 thread on python-ideas, I've collected > feedbacks in the discussion and pull-request, and tried improvement for the > API specification and reference

Re: [Python-Dev] [python-committers] Python 3.3.7 release schedule and end-of-life

Hello, 2017-07-15 23:51 GMT+02:00 Ned Deily : > To that end, I would like to schedule its next, and hopefully final, > security-fix release to coincide with the already announced 3.4.7 > security-fix release. In particular, we'll plan to tag and release 3.3.7rc1 > on Monday

[Python-Dev] PEP 539 (second round): A new C API for Thread-Local Storage in CPython

Hi python-dev, Since Erik started the PEP 539 thread on python-ideas, I've collected feedbacks in the discussion and pull-request, and tried improvement for the API specification and reference implementation, as the result I think resolved issues which pointed out by feedbacks. Well, it's