Progress Bars in Python

Re:Progress Bars in Python by user2426679 on Tuesday December 18, 2018 @12:38PM (#18708569)

edit: how the hell does markdown/code-snippet work on hackernews?! Nicely formatted pic of the below text soup:

https://i.imgur.com/fvEeaJA.png

My library function is:

import sys def writeToTerminal(txt, line_len=79): # line_len is the max num of characters that can fit onto a terminal line without overflowing to a newline

		# overwrite the line with blank spaces
		# this takes care of the case where len(txt) is fewer than the [ len(txt) when this function was last called ]
		sys.stdout.write( "\r" + " "*line_len )
		sys.stdout.flush()
        
		# write the txt, trimming to line_len
		sys.stdout.write( "\r" + txt.replace("\t", "    ")[:line_len] )
		sys.stdout.flush()

Example usage:

from time import sleep L = list(range(10)) for c, i in enumerate(L, start=1): writeToTerminal("%i / %i" %(c, len(L))) sleep(1)

[ Parent | on HN ]

Re:Progress Bars in Python by dragonwriter on Wednesday December 19, 2018 @04:08PM (#18719639)

> how the hell does markdown/code-snippet work on hackernews?!

It doesn't.

You can indent two spaces to get monospaced, unwrapped text, and that’s all the code formatting you get.

[ Parent | on HN ]

Re:Progress Bars in Python by detaro on Tuesday December 18, 2018 @12:41PM (#18708603)

So it doesn't autodetect the terminal width, and thus doesn't do the same as the library?

[ Parent | on HN ]

Re:Progress Bars in Python by cat199 on Wednesday December 19, 2018 @04:03PM (#18719585)

it shows a progress indicator, which is functionally the same from a user perspective.

the visual display of this progress indicator is different yes -

This method doesn't need any notion of terminal width because it just prints 'N / N' at the beginning of the current line where the cursor is when called.

[ Parent | on HN ]

Re:Progress Bars in Python by user2426679 on Thursday December 20, 2018 @01:05AM (#18722822)

I tend to side with your opinion (obviously, based on the above code), but detaro does have a point, which is that the progress message will "overflow" onto a new/next line in the console if the message has more characters than will fit on a single of the terminal.

fwiw, line_len=79 is the default on both windows and linux ime. You would only encounter overflow if you (1) shrunk the terminal from its default width and (2) printed a message that was longer than that shrunken width.

If you really needed to have a progress bar that accounted for a shrunken display, it could be accomplished trivially with Python 3.? and less-trivially with Py2.

I could see depending on this library if the application was client facing and needed to be automagically pretty.

Also, one thing to note is that tqdm only fetches the console width when init'ing a progress bar... if you shrink the terminal while a progress bar is still "in progress," you will encounter the same overflow issue.

[ Parent | on HN ]