For the 3.3, make _abcoll (which is full of the collections abstract base classes) visible as a module called collections.abc and document that as the preferred way to access them.

For backwards compatibility, continue to import the names directly into the collections.py namespace so that no one has to change existing code.

Background:  Experience with teaching ABCs and dealing with bug reports has shown that it is creating some confusion having the long list of abstract APIs commingled with the concrete APIs (for example, seeing collections.Mapping and thinking it is one of the various concrete types in the collections module).  If it were to become a practice to write collections.abc.Mapping, it would be immediately clear that an ABC was being used rather than a concrete class like OrderedDict.

The other reason to separate them is that the use cases tend to be different.  People look to the abstract APIs either for a specification (reference purposes), for mixin methods (aid in building their own classes), or for registration (to control isinstance and issubclass).  In contrast, people use concrete APIs directly for managing data.  Accordingly, it makes senses to group the two different types of tools into separate toolboxes.