I don't know if this kind of thing matters, but from string import ChainMap works (imports from collections). It's used internally by string`. This was done when ChainMap was made official:
2886808#diff-4db7f78c8ac9907c7ad6231730d7900c

You can see in the above commit that configparser had _ChainMap changed to ChainMap as _ChainMap, but this was not done in string.

I wouldn't say it matter, "from configparser import _ChainMap" works too, but that's just how imports work in Python. There is not reason to do what you've done on purpose - ChainMap is undocumented and is clearly just a detail of implementation.

The fact that ChainMap pollutes namespace when doing star import ("from string import *"), however, is unfortunate. I believe there was an issue around that was supposed to add missing __all__, but I'm not able to find that issue atm.

I agree that the namespace pollution is a valid bug. It affects “from string import *” and dir(string). Normally, modules either define __all__ listing their exported names, or they are really careful to define non-exported names beginning with underscores (_). Judging by the line “import re as _re”, somebody once tried to use the second technique for the “string” module.

Silent Ghost: perhaps you were thinking of bpo-23883 (adding to __all__ in various modules). This case is the opposite: we want to limit the exported names.

The fact that ChainMap pollutes namespace when doing star import ("from string import *"), however, is unfortunate.

This is what I meant by "this kind of thing". (IPython also ignores underscored names for autocomplete suggestions, unless you start with an underscore. IPython doesn't respect __all__ by default, but that's a report for IPython's tracker.)

This case is the opposite: we want to limit the exported names.

(Well, not exactly the opposite. Same purpose.)

(Never mind that last bit. I see it now.)

I agree that the namespace pollution is a valid bug. It affects “from string import *” and dir(string).

How do I get this behavior for dir? I get '_re' in dir(string).

Okay looks like I was mistaken about dir(). It ignores __all__, and just gives you everything. But the star-import point is still valid :)

Patch fixes this the proper way by defining __all__ in the string module.

Silent Ghost: perhaps you were thinking of bpo-23883 (adding to __all__ in various modules). This case is the opposite: we want to limit the exported names.

It was one of mine, bpo-10895. Been dead for a while now.

Thanks SilentGhost, seems my brain decided not to see uppercase names :) Attached patch adds Formatter and Template as well.

Judging by the line “import re as _re”, somebody once tried to use the second technique for the “string” module.

So I think it is preferable to use this technique for ChainMap.

I added an underscore in front of ChainMap, but I kept the __all__ definition because I think it should be there regardless (like every module, basically).

Why not both?

No strong opinion on changing the name to _ChainMap, as long as it only goes into 3.6.

ChainMap___all___2.patch looks good. I would be fine with this going into 3.5 as well (ChainMap is not part of the documented API for the string module).

I’m not that fussed if the _ChainMap name is backported. I just thought it is safer to not do it; similar reasoning to why I only committed bpo-23883 patches to 3.6. I certainly think backporting __all__ is reasonable.

New changeset 8136f9623d7f by Zachary Ware in branch '3.5':
Issue bpo-26809: Add __all__ to string module. Patch by Emanuel Barry
https://hg.python.org/cpython/rev/8136f9623d7f

New changeset 21ae58b77924 by Zachary Ware in branch 'default':
Closes bpo-26809: Merge with 3.5
https://hg.python.org/cpython/rev/21ae58b77924