Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guard against multiple calls to init(). #236

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

tartley
Copy link
Owner

@tartley tartley commented Nov 11, 2019

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.

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 should no longer lose the original stdout/stderr,
so that we can restore them with a single call to deinit(),
while still preserving 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.
colorama/initialise.py Outdated Show resolved Hide resolved
@wiggin15
Copy link
Collaborator

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
Copy link

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

@tartley
Copy link
Owner Author

tartley commented Dec 1, 2020

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

@malekcellier
Copy link

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
Copy link

bl-ue commented Mar 6, 2021

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

@krpatter-intc
Copy link

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
Copy link
Owner Author

tartley commented Oct 7, 2021

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants