alternative lower overhead simpler approach to #223

what do you think of this?

for i in tqdm(range(1000), ascii=" .oOX"):
  ...

Coverage decreased (-0.6%) to 90.144% when pulling 6e22bd9 on bars into 50fc2d8 on master.

Current coverage is 90.03% (diff: 66.66%)

Merging #227 into master will decrease coverage by 0.53%

@@             master       #227   diff @@
==========================================
  Files             7          7          
  Lines           477        612   +135   
  Methods           0          0          
  Messages          0          0          
  Branches         85        132    +47   
==========================================
+ Hits            432        551   +119   
- Misses           44         58    +14   
- Partials          1          3     +2   

Powered by Codecov. Last update 17bb11d...6e22bd9

Yep that's more elegant, but then the user has to care whether the env is unicode or not to supply a different custom string. You could accept a list in ascii to accept both ascii and unicode strings, and btw you won't need to do the _is_ascii check anymore.

About both approaches from my POV: this one is more elegant, but not necessarily lower overhead performance wise (3 more opcodes in the other version, in this one I think a bit more), and it wouldn't allow to make looping animated progress statuses.

For the last point, we could workaround by making a third entry in the list supplied to ascii, somewhat like this: ascii=['type', 'ascii', 'unicode'], eg, ascii=['loop', '-\|/', 'unicode version but i'm lazy'], but then we are getting a more and more complicated API for the ascii argument and it's not intuitive anymore from the name. So we should use a new argument for this I think.

So basically if we do that, we will come down to have the same thing as the variant, but by passing the custom symbols via an argument instead of inside the bar_format as a string tag. I thought about that before I wrote the other PR, and I chose the bar_format because, even if it incurs more complex string processing, at least the cost is only on users wanting to use bar_format, which is already costly in itself so the custom symbols don't change much. Also I thought it was more logical from an API point of view.

So anyway what do you think about it @casperdcl ? Is it more sensible to use an argument to pass custom symbols, or to do it via bar_format? In any case, I think that performance-wise it won't change much.

There's also the middle ground: create a new argument custom_symbols in format_meter() with format ['type', 'ascii', 'unicode'], but generate it in tqdm.__init__() from bar_format tags. No more perf hit with the tag approach, the API for ascii doesn't change, and we get a nice custom_symbols argument that we can overload in submodules (eg, for multi-line bars printing).

/EDIT: implemented in #223.

hmm. looping imho is bad practice as you're loosing info. it's better to pass in the entire alphabet as the argument. ascii = ''.join(map(chr, range(65, 91))) and if you want a spinner to loose that info but "look less scarily full of info" then ascii='/-\\|' * 8 + '#' will probably suffice. I agree that ascii looses its meaning as an argument name, though

How does codecov get the colorful highlighting? I want it too!

    ``` diff
    + green
    - red
    ```

(to explicit Casper's answer)

@casperdcl Losing bar info is actually what was asked in an old issue (and again in #228). Some user wanted to limit the size of the whole progress info line so he wanted to reduce the bar to a simple looping character, because anyway the bar is but a redundant info (we already have the percentage, ETA, it/s etc.).
Also, looping symbols paves the way for animated ascii art in the future (my patch supports any number of characters per symbol), hopefully in a way similar to fish, which is actually what I'm aiming for with this patch being the first step.

But since there are more and more requests to make custom bars animations, I'm wondering if we should really do this in the core or in a separate module, even if we have to duplicate status_printer code (eg, to implement #228 we should always check and process bar_format even when there is no total!).

@casperdcl How did you know? Gimme more hidden formatting features! I love hidden formatting features! (like the sub sup one I told @lrq3000)

Codecov Report

Merging #227 into master will decrease coverage by 0.77%.
The diff coverage is 81.81%.

@@            Coverage Diff             @@
##           master     #227      +/-   ##
==========================================
- Coverage   99.19%   98.42%   -0.78%     
==========================================
  Files          10       10              
  Lines         747      761      +14     
  Branches      132      138       +6     
==========================================
+ Hits          741      749       +8     
- Misses          2        6       +4     
- Partials        4        6       +2