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

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.

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 #25315).

> 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.

I agree with Raymond.