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

[Steve D'Aprano]

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

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

Right. Not everything needs to be a feature of the language itself,
especially if it is operating system dependent and can be delegated to the
OS.


>> 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?

Not really. I don't see this is as a useful language feature. 



> (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.)

Key-at-a-time events are solved. I've already linked to a working solution
for that, which supports both Windows and Unix/Linux. Its not in the base
language because its not as useful as you insist, and those who need it
have alternatives. Not everything needs to be in the base language.



>>> 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).

Bart, don't be naive. The C language isn't going to "acquire a slick new
enhancement" based on a few emails on compl.lang.c. C is an ISO-standard.
Stability of the language, the fact that you have a known set of
functionality, is precisely why it was made a standard in the first place:
to discourage the sort of "wouldn't it be cool if..." pile up of features
and bloat and ever-changing language specs.

You are *incredibly* privileged to do all your work on your own custom
programming languages, where you get to choose what platforms to support
("whatever PC I am using this year") and have a user-base of exactly one
user ("me"). 


> 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!

So what?

That sounds harsh, and it is intended to. Screw 'em. Who cares if a dozen
people have to write their own three line function to do something?

The Python core developers are not a magic genie that you get to snap your
fingers and they will do your coding for you. They are (for the most part,
with one or two part-time exceptions) volunteers who take time out of their
busy lives to work on Python. Time that they might otherwise be spending
with their families or making a living. Have you seen the bug tracker? They
don't have either the time or manpower to keep up with the number of
enhancements and bug fixes requested.

Any new feature has to be weighed up by these volunteers:

- Nobody is paying me to do this. Do I care about this feature 
  enough to implement it when I could work on something more 
  important instead?

- If I add this new feature, will people actually use it? Or is
  this something that sounds important but in practice will be 
  used by hardly anyone? Am I wasting my time?

- Even useful features have cost. They add to the cost of the 
  Python compiler and standard library: more code, more bugs,
  more documentation, more tests, more features to learn, more
  complex code base, and larger downloads. Is it worth the cost?

The size of Python isn't important to *you* on your fancy PC with entire
gigabytes of hard drive, but to people interested in running Python on
embedded hardware and micro-computers, every kilobyte counts.

- And more important than the physical size is the size and shape
  of the learning curve, both to use Python and to maintain it. 
  Every new feature makes the language bigger and raises the 
  barrier to entry for new users before they can say they have 
  mastered the language.

So no, not every feature belongs in the core language, or even in the
standard library. 



>>>    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"

Here's an alternative spelling:

    readh a
    readr b
    reads c

Or if you prefer more Pythonic syntax:

   a = read_hexint()
   b = read_float()
   c = read_string()


And we're back to what started with.

 
> 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.

Intuitive to whom? To me, it just looks weird.




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