Weird characters in Shell after importing seleniumbase

I have a small annoyance with seleniumbase: after importing it, printing to the Shell window will always add strange characters like "[0m" for some reason. See the image to show what I mean.

Is there a way to make these characters go away? I'm sure it happens just because of importing something from seleniumbase.

seleniumbase uses colorama to be able to print ANSI codes even on terminal that do not support ANSI codes. Basically (I've discovered that a few minutes ago, so not 100% sure) what it does is subsuming stdout and stderr to strip them from any ANSI code if it detects that the real terminal (wherever original stdout and stderr go) doesn't support ANSI code. And apparently, in the process, if it detects that terminal is supporting ANSI codes, it does add some ESC[m (which means, as already pointed out in comments, "do nothing". That is abort any previous action to change color or style) even to lines that otherwise would contain nothing.

Here, the detection of whether the real terminal does support ANSI code is what fails.

So, I would say that this is a bug, or at least of failure (colorama docs only say they "try" to detect. So, technically, if they try and fail, it is still not a bug, since doc didn't promise "try and succeed" :D) of colorama

Now, solution is quite simple: deactivate colorama.

from seleniumbase import Driver
print('hi')
# hi ^[[0m
import colorama
colorama.deinit()
print('hi')
# hi

Three notes tho:

1. It is important to do that after any seleniumbase initialization occur. Because else, it could reactivate it. (I tested it. If you call deinit before from seleniumbase..., it does reinit colorama. Besides, I was even lucky that it is all it does when I do so. Because nothing in colorama docs says it is allowed to call init after deinit (and it says that it is forbiddeng to call init more than once)
2. This is (a bit like the NO_COLOR attempt in comment) a bit reverse engineering what seleniumbase internally does. Nothing in seleniumbase documentation says that they use colorama, and therefore that you can deactivate it that way, or that they don't reinit it every minutes, or... Obviously, it works. And among reverse engineering solution, it can be classified as a very reasonable one. It is obvious that they use colorama and my warning about them potentially reinit every minute is pure fantasy speculation; it won't happen. And if future version of seleniumbase stop using colorama, it won't hurt to still deactivate it. So, this warning about reverse engineering is not as serious are most warning about reverse engineering are (and after all, usually seleniumbase user aren't the best people to argue against reverse engineering). But still, if you need an absolute guarantee that your print will never, neither now, nor in future version of seleniumbase generate unwanted ANSI code, this is not one.
3. There is probably a reason why seleniumbase bothers to do that. It is probably because it might use some ANSI code for some legit reason. So having deinitialized colorama behind its back might alter seleniumbase correct functioning afterward. My solution does remove the unwanted ANSI code, but does not guarantee that everything can work fine without them (I honestly don't know selenium well. So I don't know how and why it could badly need ANSII code to work. Just another fantasy, but if selenium does print(" K\033[2DO\033[1C test") relying on ANSI code to make that "OK test", but it prints "KO test" on your idle, because we alter its pipe... Of course, I do not believe for a moment that this could happen. But, still, theoretically, it could, and if it would, it would be your fault, not theirs :D)