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

[BartC]

On 27/10/2016 17:13, Steve D'Aprano wrote:
> On Fri, 28 Oct 2016 12:13 am, BartC wrote:

>> Doubtless your solution would be some large sledgehammer to crack this
>> particular nut.
>
> *shrug*
>
> Python's a pretty high-level language. Not every low-level feature needs to
> be part of the Python language. This sounds like something you would write
> in a low-level language like C or Rust, turn it into a extension file, and
> call it from Python.

I tend not to separate out which applications which are suitable for 
low-level and which are better for high-level languages.

And I've seen things like 'import msvcrt', 'import winapi' in Python 
code, and then there's all that stuff with ctypes.

It look like other people don't worry about that either. Although if the 
language is really unsuitable then they'll find out when it runs too 
slowly to be practical.

> You could always check the source code to the Python debugger. Presumably it
> already solves this. There has to be *some* solution. After all, operating
> systems, text editors, shells, GUI frameworks, etc. all support this.

Yes, all those kinds of application need these basic features. Isn't it 
odd then that not a single mainstream language provides them as standard?

(From my point of view the discussion has been about any key-at-a-time 
events rather than blocking or not. Those are also problematical.)

>> I'm not familiar with that many languages. However if you google for
>> '<language> non-blocking keyboard' then it seems quite a few people are
>> interested in the feature!
>
> *shrug* My very first response suggested that many people ask for this
> feature, but then after writing code to implement it, they find they don't
> actually need it. Maybe I'm wrong. But if this is so useful, outside of
> specialist areas, why do so few languages support it?

For years I've had discussions in comp.lang.c about things that C should 
or should not have. What usually happens is that someone comes up with 
some crude workaround using macros, so there is less need to have some 
feature built-in (and the language fails to a acquire a slick new 
enhancement).

But with the usual trouble that everyone then has to re-invent the same 
macro but in a different way to everyone else.

The same thing probably happens with a low-level keyboard API. There are 
half a dozen ways of achieving the same functionality (with varying 
degrees of hassle), so maybe the language doesn't need to provide a 
standard solution after all.

You talk about not wanting to re-invent things, but that's exactly what 
everyone ends up doing!

>>    print "Enter 3 numbers: "
>>    readln a,b,c
>
> How is the interpreter supposed to know that a, b, c are numbers? What sort
> of numbers? 16-bit integers, 80-bit floats, Bignums, complex, Fractions, or
> something else?

> But in a dynamically typed language, the compiler has no idea what you
> expect a, b and c to be. So it returns text, and you can convert it
> yourself.

So you tell it what to expect. The above example is from a dynamic 
language, and will assume integers unless told otherwise. This:

   readln a:"h", b:"r", c:"s"

reads a hex integer, floating point number and a string respectively 
(with a default set of separators delimiting the string, or "..." can be 
used). Or values can be read one at a time:

  readln
  read a:"h"

I think this came up when someone wanted to switch from Visual Basic to 
Python. The above is not a very sophisticated approach but it is very 
simple and intuitive.

-- 
bartc