Why doesn't Python include non-blocking keyboard input function?

[Steve D'Aprano]

On Fri, 28 Oct 2016 09:02 am, BartC wrote:

> I notice that when it comes to reading command-line arguments, then
> Python's sys.argv presents them as a list, not one long string.

Yes, just like the shell presents it to Python. It would be silly for Python
to take the list of strings it receives, join them into a single string,
and then have the user split it up again.

Not to mention the possible ambiguity if any of the arguments contain
spaces.



> And the list is just a series of strings, so needing to know whether any
> parameter was a number or whatever obviously wasn't a problem. It just
> makes each item into a string (actually that might be a better default
> than mine).
> 
> This is a very similar issue to reading items from a line of user input.
> 
> So why doesn't sys.argv just return a single string if a line is so easy
> to parse?

I don't understand your question. Who said strings are necessarily easy to
parse?

Strings *might* be easy to parse if you know what the string represents
ahead of time: "a sequence of integers, separated by spaces" is easy. But
not all data is that simple: "a valid Perl program" is notoriously
difficult. As they say, nothing but Perl can parse Perl. Likewise for C++.

The shell cannot make many assumptions about the data is it passing on. All
it knows is that it has received a sequence of characters. It cannot know
what the receiver intends to do with them, or what those characters
represent. Just because the characters are "1234" doesn't mean that they
represent the integer 1234.

I say *many* assumptions rather than *any* because, of course, any shell is
permitted to make whatever assumptions it likes! If you don't like the
shell's rules, use a different shell! But in general, shells tend towards
*minimal* interpretation of arguments: spaces separate arguments unless
escaped, for example, and a handful of special characters like * ? & ! are
given special meaning.


> (That's exactly what Windows' WinMain() function does - optional entry
> point for executables under Windows. But C's main() entry point chops
> the command line up into separate strings like Python.
> 
> Also - this might some bearing on why Python does it that way - under
> Linux, a parameter such as *.py is replaced by the names of ALL the
> files that end in .py.

That's a feature of the shell. I expect you're probably using bash, as
that's the most commonly used shell, but other shells do the same.

There's probably a way to turn that off, but I don't know it. If you want to
pass a literal star * you need to escape it so that the shell won't treat
it as a glob and expanding it: \*.py or "*.py" will probably work.

(And yes, shell escaping is one of the more arcane and tricky part of Unix
shell scripting.)



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