On 10 July 2016 at 11:15, Brett Cannon wrote:
> On Sat, 9 Jul 2016 at 06:52 Nick Coghlan wrote:
>> That issue was opened due to a few things that work with the C
>> implementation that fail with the Python implementation:
>>
>> - the C version can be pickled (and hence used with multiprocessing)
Hello all, and thanks Nick for starting the discussion!
Long wall of text ahead, whoops! TL;DR - everyone seems to agree, let's do
it.
I think the main issue that we're hitting is that we (whatever you want "we"
to mean) prefer to make Python code in the standard library as easily
understandable
On Sun, Jul 10, 2016 at 10:15:33AM +1000, Nick Coghlan wrote:
> On 10 July 2016 at 05:10, Steven D'Aprano wrote:
> > The other side of the issue is that requiring exact correspondence is
> > considerably more difficult and may be over-kill for some uses.
> > Hypothetically speaking, if I have an o
On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano wrote:
> (1) How much extra effort are we going to *mandate* that core devs put
> in to hide the differences between C and Python code, for the benefit of
> a small minority that will notice them?
>
The subject line is raising one specific differen
On 07/10/2016 08:32 PM, Chris Angelico wrote:
On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano wrote:
(1) How much extra effort are we going to *mandate* that core devs put
in to hide the differences between C and Python code, for the benefit of
a small minority that will notice them?
The su
On Mon, Jul 11, 2016 at 4:25 PM, Ethan Furman wrote:
> On 07/10/2016 08:32 PM, Chris Angelico wrote:
>>
>> On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano
>> wrote:
>>>
>>> (1) How much extra effort are we going to *mandate* that core devs put
>>> in to hide the differences between C and Python