On Wed, Sep 6, 2017 at 3:49 AM, INADA Naoki wrote:
> OK, I stop worring about thread safety and other implementation
> detail behavior on edge cases.
>
That sounds like overreacting. At the risk of stating the obvious:
I want the data structure itself to maintain its
https://www.youtube.com/watch?v=pNe1wWeaHOU=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i=1
On Wed, Sep 6, 2017 at 5:49 PM, INADA Naoki wrote:
> OK, I stop worring about thread safety and other implementation
> detail behavior on edge cases.
>
> Thanks,
>
> INADA Naoki
OK, I stop worring about thread safety and other implementation
detail behavior on edge cases.
Thanks,
INADA Naoki
On Wed, Sep 6, 2017 at 7:40 PM, Paul Moore wrote:
> On 6 September 2017 at 11:09, Antoine Pitrou wrote:
>> On
On 6 September 2017 at 11:09, Antoine Pitrou wrote:
> On Wed, 6 Sep 2017 11:26:52 +0900
> INADA Naoki wrote:
>>
>> Like that, should we say "atomic & threadsafe __setitem__ for simple
>> key is implementation detail of CPython and PyPy. We recommend
On Wed, 6 Sep 2017 11:26:52 +0900
INADA Naoki wrote:
>
> Like that, should we say "atomic & threadsafe __setitem__ for simple
> key is implementation detail of CPython and PyPy. We recommend
> using mutex when using OrderedDict from multiple thread."?
I think you may be
>
>> For example, when one thread do `od[k1] = v1` and another thread do
>> `od[k2] = v2`,
>> result should be equivalent to one of `od[k1] = v1; od[k2] = v2;` or
>> `od[k2] = v2; od[k1] = v1`. And internal data structure should be
>> consistent.
>
> I agree the pure Python OrderedDict is not
On 9/5/2017 2:20 PM, INADA Naoki wrote:
On Wed, Sep 6, 2017 at 2:13 AM, Eric Snow wrote:
Like Antoine, I consider the pure Python implementation to be
valuable. Furthermore, the pure Python implementation is the
reference, so its behavior is idiomatic.
To this
On Wed, 6 Sep 2017 03:20:43 +0900
INADA Naoki wrote:
> What is *idiomatic*? For example, in this test case:
>
> https://github.com/python/cpython/blob/564a2c68add64ebf2e558a54f5697513b19293cb/Lib/test/test_ordered_dict.py#L575-L582
>
> def test_dict_delitem(self):
>
First of all, I saw enough -1 so I gave up about removing.
Following reply is just a technical topic.
On Wed, Sep 6, 2017 at 2:13 AM, Eric Snow wrote:
[snip]
>
> Like Antoine, I consider the pure Python implementation to be
> valuable. Furthermore, the pure Python
On 9/5/2017 10:40 AM, Guido van Rossum wrote:
On Tue, Sep 5, 2017 at 5:58 AM, Simon Cross
>
wrote:
I thought the decision a few years ago was that all modules that
have a C library for performance reasons should also
On Tue, Sep 5, 2017 at 12:13 PM, Eric Snow wrote:
> On Tue, Sep 5, 2017 at 1:38 AM, INADA Naoki wrote:
>> Like that, how about removing OrderedDict Pure Python implementation
>> from stdlib and require it to implementation?
>
> -1
>
> Like
On Tue, Sep 5, 2017 at 1:38 AM, INADA Naoki wrote:
> Like that, how about removing OrderedDict Pure Python implementation
> from stdlib and require it to implementation?
-1
Like Antoine, I consider the pure Python implementation to be
valuable. Furthermore, the pure
On Tue, Sep 5, 2017 at 5:58 AM, Simon Cross
wrote:
> I thought the decision a few years ago was that all modules that have a C
> library for performance reasons should also have a Python version? Did this
> decision change at some point? (just curious).
>
It was
On Tue, 5 Sep 2017 17:38:06 +0900
INADA Naoki wrote:
>
> Like that, how about removing OrderedDict Pure Python implementation
> from stdlib and require it to implementation?
I don't like this. The C version of OrderedDict is probably very hard
to read, while the Python
On Tue, Sep 5, 2017 at 8:48 PM, Serhiy Storchaka wrote:
> 05.09.17 11:38, INADA Naoki пише:
>>
>> ## Cons
>>
>> * All Python 3.7 implementations should provide _collections.OrderedDict
>>PyPy has it already. But I don't know about micropython.
>
>
> Current C
On Tue, Sep 5, 2017 at 9:58 PM, Simon Cross
wrote:
> I thought the decision a few years ago was that all modules that have a C
> library for performance reasons should also have a Python version? Did this
> decision change at some point? (just curious).
But in this
I thought the decision a few years ago was that all modules that have a C
library for performance reasons should also have a Python version? Did this
decision change at some point? (just curious).
___
Python-Dev mailing list
Python-Dev@python.org
05.09.17 11:38, INADA Naoki пише:
## Cons
* All Python 3.7 implementations should provide _collections.OrderedDict
PyPy has it already. But I don't know about micropython.
Current C implementation of OrderedDict is not safe regarding using
mutating dict methods (or dict C API) like
Hi, all.
Currently, deque and defaultdict have only C implementation.
Python implementations should provide _collections.deque
and _collections.defaultdict.
Like that, how about removing OrderedDict Pure Python implementation
from stdlib and require it to implementation?
## Pros
### Thread
19 matches
Mail list logo