"\x1b[1A" in a loop (to go up N lines) can be replaced by f"\x1b[{num_lines}A" without any loop.
Also, rather than hardcoding cryptic \x1b[1A and \x1b[2K, it would be more portable and readable to use the dedicated terminfo/termcap, which are names for those arbitrary sequences (though termcap/terminfo names can still be a bit cryptic).
For example in shell: printf '\x1b[1A' can be replaced with tput up 1 (for go up 1 line).
In Python, it’s possible to use terminfo/termcap through the curses module.
I’d tell anyone who gets the itch to implement fancy console output to please please please use platform agnostic library abstractions instead of directly coding in escape sequences and always degrade gracefully into plain old line based text output and/or streaming json so that you don’t sacrifice interoperability and re-usablility to add a very narrow bit of ergonomics; even well intention things to make your interface more “human” can easily come at the expense of humans who need things like screen readers.
I honestly couldn’t tell you as I am not a screen reader user, but… if your code DTRT with regards to checking terminal capabilities I would presume that you would avoid the pitfalls with attempting to do things which the terminal is incapable of doing.
"\x1b[1A"in a loop (to go up N lines) can be replaced byf"\x1b[{num_lines}A"without any loop.Also, rather than hardcoding cryptic
\x1b[1Aand\x1b[2K, it would be more portable and readable to use the dedicated terminfo/termcap, which are names for those arbitrary sequences (though termcap/terminfo names can still be a bit cryptic).For example in shell:
printf '\x1b[1A'can be replaced withtput up 1(for go up 1 line). In Python, it’s possible to use terminfo/termcap through the curses module.To paraphrase Michael Pollan, “write code, not too much, mostly procedural”
I’d tell anyone who gets the itch to implement fancy console output to please please please use platform agnostic library abstractions instead of directly coding in escape sequences and always degrade gracefully into plain old line based text output and/or streaming json so that you don’t sacrifice interoperability and re-usablility to add a very narrow bit of ergonomics; even well intention things to make your interface more “human” can easily come at the expense of humans who need things like screen readers.
Do the library abstractions work out ok for screen reader users, or are they roughly as unfriendly as hardcoded ANSI?
I honestly couldn’t tell you as I am not a screen reader user, but… if your code DTRT with regards to checking terminal capabilities I would presume that you would avoid the pitfalls with attempting to do things which the terminal is incapable of doing.