Yeah when there’s any possibility that an imported name is too generic to tell from which module it’s imported, import the module itself and access the name as an attribute of the module instead.
Yes, except when you legitimately need all the imported names when forwarding them from a submodule to an exposed API (which still doesn’t provide a reason for the OP’s proposal):
Which is why it exists. There definitely are use-cases for star imports, so we don’t want something stupid like for name in dir(module): globals()[name] = getattr(module, name) to do those reexports. No, we have a proper language feature for that!
But any time you have multiple star imports, they have to be cooperative. Multiple submodules being merged? Sure! Two entirely independent modules being used in an application? Bad idea.
There certainly are good use-cases for “import everything, except these names”. However, in many cases, it’s better handled in the module itself - eg “import sys as _sys”, or explicitly defining __all__. I have sometimes wondered if there could be a way to call on the default implementation of __all__ and then make your own changes, but I wouldn’t push for that as I don’t have any concrete use-cases for it; it would, however, offer another option for “remove those things from __all__ before we return” if that’s what people want.
import collections
collections.__all__.remove('Counter') # unittest.mock.patch for temporary mod
from collections import *
OrderedDict # OK
Counter # NameError
You can currently define __all__ in the positive way (listing all the things you WANT to be included), and you can adorn names so they get excluded (with a leading underscore), but you can’t say “let the default algorithm do its stuff, but then exclude these names”. Notably, the only way to exclude names from a star import while still having them directly importable is to fully list out everything you want to be star-importable. (As an example, from collections import * will not import abc, but you can from collections import abc.)
Anyhow, I don’t think this is a huge use-case, since it can often just be done positively, but I do think that this is usually better handled in the module than in the place it’s imported.