Keep the link to Python implementation of OrderedDict

[serhiy-storchaka]

BPO	25623
Nosy	@rhettinger, @ericsnowcurrently, @serhiy-storchaka, @Vgr255
Files	OrderedDict_python_impl.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2015-11-20.18:06:38.425>
created_at = <Date 2015-11-14.08:12:48.340>
labels = ['type-feature', 'library']
title = 'Keep the link to Python implementation of OrderedDict'
updated_at = <Date 2015-11-20.18:06:38.424>
user = 'https://github.com/serhiy-storchaka'

bugs.python.org fields:

activity = <Date 2015-11-20.18:06:38.424>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2015-11-20.18:06:38.425>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2015-11-14.08:12:48.340>
creator = 'serhiy.storchaka'
dependencies = []
files = ['41038']
hgrepos = []
issue_num = 25623
keywords = ['patch']
message_count = 5.0
messages = ['254645', '254698', '254702', '254707', '255000']
nosy_count = 4.0
nosy_names = ['rhettinger', 'eric.snow', 'serhiy.storchaka', 'abarry']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue25623'
versions = ['Python 3.5', 'Python 3.6']

[serhiy-storchaka]

For now C implementation of OrderedDict totally overrides Python implementation.

>>> import collections
>>> collections.OrderedDict.__init__
<slot wrapper '__init__' of 'collections.OrderedDict' objects>                                                                

The only way to get Python implementation of OrderedDict is to block the _collections module and reload the collections module.

>>> del sys.modules['collections']
>>> del sys.modules['collections.abc']
>>> sys.modules['_collections'] = None
>>> import collections
>>> collections.OrderedDict.__init__
<function OrderedDict.__init__ at 0xb6f6da4c>

But this also blocks collections.deque, collections.defaultdict, and the acceleration of collections.Counter.

As long as C implementation of OrderedDict still has some bugs (and I'm not sure we will have fixed all them before releasing 3.5.1), I think it would be good to have a workaround for applications that encounter one of still not fixed bugs.

I propose to keep a reference to Python implementation as collections._OrderedDict. This is not a public interface and we don't promise existing this name in future releases. This is just a way to make a workaround for the time while C implementation is not stable enough. I hope we will got rid from it in 3.7.

A workaround for an application that suffers from OrderedDict bug:

import collections
try:
    collections.OrderedDict = collections._OrderedDict
except AttributeError:
    pass

[rhettinger]

I think we should stick with fixing bugs as found (even if that process spills into 3.5.2). The current tests do a good job of making sure the basic functionality is in place and there has been use in the field. Also, you've already done a good job fixing a few of the most egregious bugs.

Likewise should have an aversion to temporary APIs like _collections and to API changes between micro releases. In general, this strategy is likely to cause more pain than it alleviates. So, put me down for -1 on this one.

[Vgr255]

I would personally suggest a more permanent and accessible way, in the way the decimal module handles it. I'd add a '_pycollections' module holding the pure Python implementations of OrderedDict and _count_elements, then have the collections package import them if the C accelerators don't work.

While the '_pydecimal' module is not guaranteed to remain across versions, successfully importing it means that you are guaranteed to use the pure Python version of it. In the same direction, successfully importing OrderedDict from _pycollections would guarantee that you're using the pure Python version of it.

This would have the side-effect of allowing people relying on the pure Python implementation details to use them (see bpo-25315).

[rhettinger]

This would have the side-effect of allowing people relying
on the pure Python implementation details to use them

Right. That's why we don't want to do this.

[ericsnowcurrently]

I agree with Raymond.