Could tqdm default to redirecting std{out,err} to tqdm.write?

[anntzer]

I don't think it ever makes sense to print to the default stdout when in a tqdm loop (I may be wrong?), so perhaps it would make sense to default to enabling the writing redirection (with a kwarg to opt-out)?

[lrq3000]

I don't think that's a good idea, libraries should never mess with the
standard IO. Plus there is no general case to cober because some people
will write messages to stdout, others to a log managed manually, others by
using the logging lib, others by writing to stdout but fork output to also
write in a log file (as I do), etc.

So we can provide code snippets but i don't think it's wise to implement
these as part of the lib. Unless something very elegant and general purpose
can be found.
Le 27 Oct. 2016 07:55, "Antony Lee" notifications@github.com a écrit :

I don't think it ever makes sense to print to the default stdout when in
a tqdm loop (I may be wrong?), so perhaps it would make sense to default to
enabling the writing redirection (with a kwarg to opt-out)?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#296, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABES3r5Q_ySnEp_AXj_WKxp2QgUGnM-gks5q4DzXgaJpZM4Kh-EE
.

[anntzer]

Doesn't the example provided in the "redirecting writing" section of tqdm.github.io cover all the cases that you suggest? Please let me know if there are any specific counter-examples.

[lrq3000]

No because for example you have to use a different wrapper if you want to redirect logging module output. I don't think there is a way to allow for generic redirection, this is a per application need...

[anntzer]

No, logging (or more specifically, StreamHandler) just writes to whatever stream you asked it to write to (by default, it looks up sys.stderr every time it needs to emit a message, see https://hg.python.org/cpython/file/3.5/Lib/logging/__init__.py#l969 and https://hg.python.org/cpython/file/3.5/Lib/logging/__init__.py#l1051).

I find it a bit funny that I need to be claiming that your code is has more capabilities than what you believe, but let's play a game: assume that the stdout_redirect_to_tqdm context manager (from the "redirecting writing" example) was applied to each tqdm loop. Could you come up with a minimal example where this would lead to unexpected behavior?

[lrq3000]

It's not that I doubt tqdm's capabilities, but rather that I fear automatic output redirection. We don't want tqdm to mess with parent apps, and output redirection is generally a big mess, so my opinion is that we should avoid providing an automated way to do that. But that's just my opinion...

[anntzer]

What about providing a kwarg to tqdm.tqdm() (say, redirect=True) that would enable the redirection? Then lazy enough devs can try using it (I may just write tqdm = partial(tqdm, redirect=True)), and you'll see whether anyone reports a bug :-)

[cledoux]

I'd really like to see this implement, either as an option or via a tqdm provided context manager. Personally, I'd prefer the option suggested by @anntzer because I am a lazy dev. 😄

I think tqdm provided context manager would also be an acceptable compromise. Something that basically implements the example given in the README.

import tqdm
with tqdm.redirect_stdout():
    for i in tqdm.tqdm(range(10)):
        print(i)

I can put together a PR if there is interest in this. What do you think?