Le ven. 19 oct. 2018 à 19:01, Stephane Wirtel a écrit :
> total: 49 PRs
> is:open is:pr review:approved status:success label:"awaiting merge"
> -label:"DO-NOT-MERGE" label:""LA signed""
I merged many PRs and closed a few (2 if I recall correctly). Your
query now counts 24 PRs.
Victor
__
On Fri, Oct 19, 2018 at 5:01 AM Sean Harrington
wrote:
> I like the idea to extend the Pool class [to optimize the case when only
> one function is passed to the workers].
>
Why would this keep the same interface as the Pool class? If its workers
are restricted to calling only one function, that
Of those 49 PRs, 18 are by core developers themselves, so 31 PRs are by
external contributors that seem ready to be merged.
There was a discussion at one point on core-workflow about changing the
default "needs" label for PRs by core devs which in this instance would
help with providing a search f
Hi all,
How are you? I am fine ;-) and you?
So, on this morning I was playing with the github interface and the
pull requests of CPython and I have discovered the advanced search of
Github and I think this one is really useful for us and certainly for
the core-dev.
So, I was interested by somes
ACTIVITY SUMMARY (2018-10-12 - 2018-10-19)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6835 (+11)
closed 39943 (+50)
total 46778 (+61)
Open issues wi
On Fri, Oct 19, 2018 at 7:32 AM Joni Orponen wrote:
> On Fri, Oct 19, 2018 at 9:09 AM Thomas Moreau <
> thomas.moreau.2...@gmail.com> wrote:
>
>> Hello,
>>
>> I have been working on the concurent.futures module lately and I think
>> this optimization should be avoided in the context of python Poo
On Fri, Oct 19, 2018 at 9:09 AM Thomas Moreau
wrote:
> Hello,
>
> I have been working on the concurent.futures module lately and I think
> this optimization should be avoided in the context of python Pools.
>
> This is an interesting idea, however its implementation will bring many
> complicated
Hello,
I have been working on the concurent.futures module lately and I think this
optimization should be avoided in the context of python Pools.
This is an interesting idea, however its implementation will bring many
complicated issues as it breaks the basic paradigm of a Pool: the tasks are
ind
