On Oct 20, 2013, at 9:21 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> If anyone is interested in having a (faithful) C implementation of
> OrderedDict for the 3.4 release, I have a patch up [1]. My interest
> in having the patch applied is relative to proposals that won't apply
> to 3.4, so I haven't felt the need to advance the patch. However, in
> case anyone else would find it useful for 3.4, I figured I would point
> it out.
>
> While the patch isn't all that complicated, it is large and my C/C-API
> experience isn't proportional to that size. So I don't feel
> comfortable about moving ahead with the patch without at least one
> thorough review. Thanks.
I'll look at this in more detail after I've finishing my review of the TransformDict,
but my initial impression is that the original show stopper hasn't been overcome:
http://bugs.python.org/issue10977
The concrete dict API is very old and is widely used in C extensions
outside the standard library. AFAICT, there is no way to prevent that code
from bypassing your code and breaking the internal invariants of the
ordered dict (that breakage could be silent are muck up the ordering
or could fail loudly with a segfault).
If we really want a C implementation, I think the choices boil down to:
1) living with the problem and writing defensive code so that the
ordered dictionary won't segfault when fed to existing external C code
and so that the ordered dict notices whether the parent dictionary has
different keys than those in the internal linked list.
or 2) biting the bullet and accepting an API change where ordered dicts
are no longer a subclass of real dicts.
Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131020/3f2e0257/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4