Prevent user from wrapping already wrapped streams

[tomchy]

Due to the fact, that colorama uses global streams, multiple wraps around the same stream is pointless and causes python to hung on both Linux and Windows-based machines.

If such behavior is allowed, huge delays inside modules, that uses colorama are introduced:

>>> import colorama
>>> import time
>>> for i in range(30):
...   start = time.time()
...   colorama.init()
...   stop = time.time()
...   print(stop - start)
...
0.002007007598876953
0.004018068313598633
0.003504037857055664
0.0030028820037841797
0.004488945007324219
0.005014896392822266
0.0025060176849365234
0.007011890411376953
0.00401616096496582
0.01253199577331543
0.013036966323852539
0.03408479690551758
0.03659701347351074
0.06968498229980469
0.13085198402404785
0.22510790824890137
0.6968679428100586
1.0372772216796875
1.97328519821167
3.6422548294067383
4.66950798034668
12.083894968032837
25.121819019317627
51.497376918792725
104.18486189842224
177.13460302352905
272.79527592658997
652.5946300029755
...

Related issues:

• Provide isinitialized function #128
• Infinite recurse on windows #140
• deinit() doesn't work if init() was called twice. #145
• RecursionError exception if init() called multiple times on Win32 #182

[Delgan]

What if user wants to init() colorama with autoreset=True while the stream has already been wrapped by a library with autoreset=False?
It looks like this implementation is going to prevent him from getting the desired result, right?

The hanging and huge delays while wrapping the same stream is a big issue indeed, it has been reported in #196 and I opened #198 to fix it.

Adding a safeguard arround multiple wrapping could be useful though to avoid RecursionError when init() is called thousands of times. However, if that happens, I think the user is doing something wrong.

[tomchy]

Hi Delgan!
Thank you for your quick response. You're right, I missed that case. There is even unit test that verifies the behaviour that you've mentioned.

This also brings another thought: if there is a test case that does a doubled initialisation, it may cause people to think that colorama may be initialised several times and the only effect should be the stream wrapper settings update. That leads to a conclusion: why calling init() thousands of times is something wrong, if a similar behaviour is presented inside unit tests?

That's also the reason why I've changed that unit test in the initial version, to avoid any further confusion in the usage of init() function.

Let me add a short story that shows how you may get into troubles with several init() calls:

1. A developer tries to make a fancy logging module, that formats each log message in a way that errors are printed in red, warnings in yellow, and infos in white.
2. Everything works perfectly on Linux, but one day he tries to use it under Windows. A well-proven solution for that is to use a mature project like colorama. The init() is called inside logger constructor, as that seems to be a logical place for it.
3. After couple of months, the module starts to be used as a primary logging method.
4. While project evolves, more instances of fancy logger are created, and one day - BOOM, everything starts to slow down, and finally - the software reaches RecursionError.

Of course, you may say - if someone does module-level initialisation at non-singleton object level, he has a bug in his code, but I bet that pasting one of unit tests would give you an approval in most of code reviews 🙂

[Delgan]

Yeah, you are probably right and your example is pretty convincible. 🙂

The fact that several people have reported encountering RecursionError problems is also a hint that something could be improved.

I can't think of any downside with your suggested change, but it should be interesting to know why it has not been implemented like this in the first time and why nested wrapping had been chosen instead.

The only surprising effect would be in this case:

1. Someone call init()
2. Someone wrap or replace sys.stderr with another stream-object
3. Someone call init() again

Then, the resulting sys.stderr would not be the one expected, but I don't know if such situation happens that often.

[tartley]

Hey. FYI, Yesterday I created a PR to test releases before we push them to PyPI. When that is merged, I'll be more confident about resuming merges and releases. I'll try to look at this PR soon. Thank you for creating it!

[tartley]

This PR dupes fixes in #236 and #262 (although this one predates those)