One reason we usually suggest that people don't use star imports is that it is too easy to shadow a builtin or overwrite an existing global.  Momma Gump always used to say, "import star is like a box of chocolates, you never know what you've going to get".

>>> from os import *
Warning (from warnings module):
  File "__main__", line 1
ImportWarning: The 'open' variable in the 'os' module shadows a variable in the 'builtins' module

>>> alpha = 2.0
>>> beta = 3.0
>>> gamma = 4.5
>>> delta = 5.5
>>> from math import *
>>> from os import *
Warning (from warnings module):
  File "__main__", line 8
ImportWarning: The 'gamma' variable in the 'math' overwrites an existing variable in the globals.

What if existing globals are overwritten intentionally? For example, the stat module defines some constant and then use the star import from _stat. Other example is the datetime module.

> What if existing globals are overwritten intentionally?

That's why it would be a warning instead of an error.  Also, with warnings we can suppress specific instances (by module or by message).

Another question will be are we going to replace the * in our source code in the future? Since I found lots of our code use 'from xxx import *' pattern.

This will force legal third-party code to add special code to suppress warnings. This is breaking change.

Other problem is with shadowing builtins. This increases chance of breakage when introduce new builtins. Currently adding a new builtin does not affect existing code which does not use this builting, but all will be changed if implement this feature.

Since shadowing a builtin and overwriting an existing global is not always an error, I think this warning should not be the part of the interpreter, but rather a part of third-party linters (which can be configured to ignore some warnings for particular projects).