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

ncols parameter bug/inconsistency in tqdm.auto #817

Open
shun-lin opened this issue Sep 22, 2019 · 1 comment
Open

ncols parameter bug/inconsistency in tqdm.auto #817

shun-lin opened this issue Sep 22, 2019 · 1 comment
Assignees
Labels
p4-enhancement-future 🧨 On the back burner question/docs ‽ Documentation clarification candidate submodule ⊂ Periphery/subclasses

Comments

@shun-lin
Copy link

Hi!

First I want to say this is a really really cool progress tool! I want to use tqdm to create a nicer looking progress bar for training models using keras and to make it compatible for most notebook and console I am importing tqdm using:

from tqdm.auto import tqdm

as per documentation. I found out that my progress bar is only using around half of the width in the output cell so I initialize my tqdm as

tqdm(ncols="100%")

This works great in notebook but when I tried to run it in console it breaks as ncols in console version is expecting an int instead of str. I was able to resolve the problem simply by setting dynamic_ncols to True instead of specifying ncols.

tqdm(dynamic_ncols=True)

Although my use-case is resolved (using 100% of width in notebook while having the same in console). The issue of ncols inconsistency still persists as in the notebook version of tqdm we also take in a string while standard tqdm doesn't. I just want to point this out here just in case someone also bump into the same issue. Let me know if you feel like this should be address (i.e. define behavior for passing in a string to ncols in standard tqdm) I am happy to help out!

Thank you so much for your time!

Environment:
python: 3.6.2
tqdm: 4.36.1

@casperdcl
Copy link
Sponsor Member

hmm yes, this is maybe something we should think about.

In future the arguments may diverge even more, and more frontends may be added.

@casperdcl casperdcl self-assigned this Sep 22, 2019
@casperdcl casperdcl added p4-enhancement-future 🧨 On the back burner question/docs ‽ Documentation clarification candidate submodule ⊂ Periphery/subclasses labels Sep 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p4-enhancement-future 🧨 On the back burner question/docs ‽ Documentation clarification candidate submodule ⊂ Periphery/subclasses
Projects
None yet
Development

No branches or pull requests

2 participants