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

2017-08-31 Thread Antoine Pitrou
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 that there is an improvement using th

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

2017-08-31 Thread Chris Angelico
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 from such an optimization. If you're

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

2017-08-31 Thread Manciu, Catalin Gabriel
>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)

2017-08-31 Thread Terry Reedy
On 8/31/2017 3:27 PM, Brett Cannon wrote: On Wed, 30 Aug 2017 at 02:56 Paul Moore do so to squash their PRs themselves. Personally, I'd prefer that as, apart from admin activities like making sure the PR and issue number references are present and correct, I think the original su

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

2017-08-31 Thread Terry Reedy
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)

2017-08-31 Thread Paul Moore
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 multiple commits and the

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

2017-08-31 Thread Brett Cannon
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 wrote: > >>> Please, please don't forget to edit commit messages before merging.

[Python-Dev] Inplace operations for PyLong objects

2017-08-31 Thread Manciu, Catalin Gabriel
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

2017-08-31 Thread Koos Zevenhoven
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 post about it, partly because of the > >> PEP550-based

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

2017-08-31 Thread Masayuki YAMAMOTO
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 started the PEP 539 thread on python-ideas, I've collec

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

2017-08-31 Thread Masayuki YAMAMOTO
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. I'd still want to keep

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

2017-08-31 Thread Erik Bray
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 implementation, as the result I thin

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

2017-08-31 Thread Nick Coghlan
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 implementation, as the result I think > re

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

2017-08-31 Thread Victor Stinner
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 2017-07-24 (UTC) and

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

2017-08-31 Thread Masayuki YAMAMOTO
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 probabl