This style of importing tends to be discouraged because it makes it much harder to determine where symbols were defined in a file that is making use of the imports. This is more a stylistic thing than anything else, however if you do wish to consider continuing to use wildcard imports like this you probably want to consider defining __all__ in your modules. This is because __all__ explicitly defines all the names that get imported when someone does from my_library import * and gives you a means to allow the calling site to import everything necessary but to give you a filter such that the internal/private/etc code does not get exported by default.
https://github.com/JamesDevJim/game-zulu/blob/4b46243499803992d0ef07bb856fb49bb8f72240/victor.py#L14-L18
This style of importing tends to be discouraged because it makes it much harder to determine where symbols were defined in a file that is making use of the imports. This is more a stylistic thing than anything else, however if you do wish to consider continuing to use wildcard imports like this you probably want to consider defining
__all__
in your modules. This is because__all__
explicitly defines all the names that get imported when someone doesfrom my_library import *
and gives you a means to allow the calling site to import everything necessary but to give you a filter such that the internal/private/etc code does not get exported by default.