Issue 26809: Add __all__ list to the string module

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:
https://github.com/python/cpython/commit/2886808d3809d69a6e9b360380080140b95df0b6#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 Issue 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 Issue 23883 (adding to __all__ in various modules). This case is the opposite: we want to limit the exported names.

It was one of mine, issue 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 Issue 23883 patches to 3.6. I certainly think backporting __all__ is reasonable.

New changeset 8136f9623d7f by Zachary Ware in branch '3.5':
Issue #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 #26809: Merge with 3.5
https://hg.python.org/cpython/rev/21ae58b77924

nosy: + python-dev
messages: + msg267302

resolution: fixed
stage: patch review -> resolved

nosy: + rhettinger

messages: + msg263851

messages: + msg263836

nosy: + abarry
messages: + msg263834

keywords: + patch