The answer by @Marcin correctly points out the way to disable this check, but it doesn't explain why.

The check is there for a reason, and by disabling it without understanding said reason, you are setting yourself up for a potential fail.

What are private imports?

"Private imports" are symbols imported by a module that are not re-exported by that same module.

To give an example, let's say there's a library named pets that provides pets and their foods:

# pets/foods.py
__all__ = ['Tuna', <other foods here...>]

class Tuna(Food): ...

# pets/cats.py
from .foods import Tuna

class Cat:
  def eat(self, food: Food) -> None: ...

def feed_cat(cat: Cat) -> None:
  food = Tuna()
  cat.eat(food)

Now, from your code, you do this:

# your_house.py
from pets.cats import Tuna  # !?

This import will not fail at runtime, since Tuna is imported into cats.py, but you should instead import it from pets.foods, where it is originally defined.

cats.py imports Tuna because that symbol is necessary for feed_cat()'s implementation, but nothing guarantees Tuna will always be present in that module. If feed_cat() were to be changed to use Chicken, the Tuna import would be removed and your code would thus break.

See also: What does __all__ mean in Python?, Why use `from module import A as A` instead of just `from module import A`.

Conclusion

The cat feeder who lives in the cat house might have a can of tuna, but they are not who you should get your tuna from.

You ought to go to the food storage instead:

from pets.cats import Tuna   # bad
from pets.foods import Tuna  # good

Sometimes, however, it might be the library which is in the wrong by not re-exporting things properly. If you think this is the case, filing an issue at the library's bug tracker would be a good start.