Is shutil.get_terminal_size useless?

Steve D'Aprano steve+python at pearwood.info
Sat Jan 28 05:49:10 EST 2017


On Sat, 28 Jan 2017 07:27 pm, Chris Angelico wrote:

> On Sat, Jan 28, 2017 at 7:03 PM, Steve D'Aprano
> <steve+python at pearwood.info> wrote:
>> But if I pipe the output to something else, the shutil version fails to
>> determine the correct terminal size, and falls back on the default:
>>
>>
>> [steve at ando ~]$ python3.5 test_gts.py | cat
>> shutil: os.terminal_size(columns=999, lines=999)
>> os: os.terminal_size(columns=116, lines=29)
>>
>>
>> while the os version gives the correct result.
> 
> I believe the problem here is your definition of "correct".

That would be the dictionary definition: 

Correct - conformable to truth; not faulty; free from error

:-P


> When you 
> inquire of the os module, you're asking, at a fairly low level, what
> the terminal window is sized to. 

Right: I want to know what the terminal window is sized to.


> But when you ask shutil, you're 
> asking what a shell utility should do. 

No, I'm asking what the terminal window is sized to. That's why the function
is called get_terminal_size(), not what_should_a_shell_utility_do().

What should a shell utility do, under what circumstances? How can any
function answer that?


> Quite a few programs change in 
> behaviour when piped into something else (for instance, 'ls' will
> often apply colour and columnate its text, but if you pipe it into
> grep, you don't want any of that),

Sure, and if I wanted to know if standard output was being piped to
something else, I'd expect to call a function called something like
where_is_std_out_being_piped_to().

The terminal size doesn't change just because I'm piping output to another
process. Using the terminal size as a proxy for "being piped" is sheer
insanity. That would be like calling

    len(some_string)

and expecting it to return None if some_string was all uppercase.


> and shutil is acknowledging that different effect.

Before there can be a *different* effect, there needs to be an *original*
effect, and I have no idea what effects you are referring to. Be precise,
please.

I don't dispute that there are times where a process may wish to change
behaviour when being piped to something else. But that's a red herring: I'm
asking what the terminal size is. I expect to get the terminal size, or
perhaps an exception if there is no terminal, with an *optional* default,
not a mandatory one.

So far it sounds like shutil.get_terminal_size() is broken by design. Can
somebody convince me it isn't?


> Both are correct answers - to different questions.

But I'm only asking one question: what's the terminal size?

It sounds like your answer is just a long, round-about way of saying "Yes,
it's useless. You cannot trust it to return the terminal size, even when
there is a terminal."


I haven't even asked what happens if it is called when there is no
associated terminal... but now I'm afraid that if I do, it will return the
number of CPUs in my computer or something...




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.




More information about the Python-list mailing list