When you do
from my_module import * it means that all functions and class declarations from my_module are available. That is the only advantage to doing this.
There are some caveats to consider:
You must know what is in the other module to know what is imported
If you don't know what functions or classes are in your 'my_module', you have to go read this module, while not intrinsically bad. New members on the project might be confused and if you go back to your code 6 months later, you might not be fully aware of what is actually imported.
Clarity is key
from my_reader import * is less clear then
from my_reader import file_reader
You risk creating collisions in imports
If you declare a function or class with the same name in two different modules and import both of them into the same file, this will cause issues. Named importing allows you override the name at import
from file_reader import read as read_file
from web_reader import read as read_website
This is a much safer method of
Knowing your dependencies
When you import just the functions and classes you need, you know exactly what the module you are working on depends on. And with tools you can build these dependency graphs if you need.
When modules change the worst is ImportError
The danger of not knowing what is collected in that star, is when a function or class is moved from a module into another. The compiler will not help you when you have a star. You would get an undefined error, which is miles more confusing than ImportError, which is easier to track down.
If you want access to any part of the module it is probably best to use
import my_module over
from my_module import *. You can access any function or object of
my_module by using the following syntax:
my_object = my_module.MyObject()
The only disadvantage is it is slightly longer but will provide better errors. It's still better to decide this style for your own project. But consider applying a bit of clean code and offering good debugging strategies in case of developer mistakes.