Guard against multiple calls to init().

[tartley]

BEWARE, I haven't tested this on Windows (because I
don't have a Windows box.) It should definitely get
tested there before we merge.

This is intended as a fix for:
#145

This PR means that multiple calls to init() should no longer
lose the original stdout/stderr references.
So we can then restore them with a single call to deinit().
It preserves the behavior that multiple calls
to init() can override the passed values for autoreset,
convert, strip, wrap.

This fix is not intended to reset output to default
foreground/background colors after the call to
'deinit()' - that was never intended behavior.

[wiggin15]

I confirmed this on Windows 7 with Python 3.5 (yes, it is old, but I think it should be enough).

One small concern I have is that passing different parameters to multiple init calls can still change the final effect. For example, if I call init once with autoreset=True and once with autoreset=False, with the current code there will be an auto-reset code sent after each "write" because we'll have two "AnsiToWin32" objects wrapping each other - one that resets and one that doesn't. With the new code, we lose the multiple wraps, causing only the latest parameters to take effect, so if the last call passes autoreset=False, we will not have an auto-reset. The same goes for the other parameters, I guess. I don't know if this is important enough (wrapping multiple times is not really a good thing), but it could cause backward-compatibility breaks.

[malekcellier]

Please consider releasing a new version, this PR does it for me on Windows 10.
Thanks!

[tartley]

Thanks for the thoughts. I'll do it any day now... :-)

[malekcellier]

Thanks a lot for responding! In my current project I had to resort to some inelegant monkey-patching which I will be more than happy to discard :-)

[bl-ue]

@tartley has the day come yet? 😄 I'd like this feature too. May it merged and a new release cut, please?

[krpatter-intc]

This PR would be a big help for some of my use cases....I'd like to build on it a bit so that future calls to init can tweak the autoreset behavior (for use within a context manager). However, I see this one is still open, so curious what the thoughts are on if this will eventually get merged or is there a reason this was never merged and I should perhaps do a new one?

[tartley]

Is this a dupe of #262 ?

Do they both suffer from the same problems wiggin describes above (ie behavior is inadvertantly changed because some calls to init, possibly with different params than last time, are discarded?)

[krpatter-intc]

There is a behavior change yes. But only depending on the order of autoreset. Today, if there is ever a call with autoreset=False, then you can never make a future call where autoreset=True works (since we just keep first init called wins)....I'd want to change that to.

Also, not sure if it is important, but each init call re-wraps stdout....the underlying assumption here is that if they want to wrap a new sys.stdout they will now need to call deinit.

I admit, I did not notice the other PR, the counter is good as it requires the same number of deinit as init calls. I also liked that this one had some tests 😄 at a quick glance it seems they may work for the other PR too.