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

[BartC]

On 27/10/2016 07:51, Steven D'Aprano wrote:
> On Thursday 27 October 2016 12:12, BartC wrote:
>
>> I don't
>> understand the argument that a language shouldn't have a basic keyboard
>> API because some computers it could run on might not have a keyboards.
>
> That's not the argument. The argument is that Python has a basic keyboard API:
> raw_input (in Python 2) or input (in 3).
>
> This supports 97% of keyboard-based interaction, namely blocking line-based
> text input. Ctrl-C (KeyboardInterrupt) can be co-opted to support maybe another
> one or two percent.
>
> The question is, what are the use-cases for the sorts of key APIs you are
> asking for? Who needs them? Why should it be a language feature?

If a language (or more likely an OS such as Unix) doesn't natively 
provide a certain feature, then it's not surprising that 97% of 
applications don't use it!

"There's a room in your house with no door to it; how do I get in?"

"There's no need for a door because no one ever uses that room! But you 
can get in through the chimney - if you /have/ to."


> Those are not rhetoricial questions.
>
> Python falls neatly into the same niche of languages as (for example) Ruby,
> Javascript, Lua, Swift, Tcl, and (not quite as well) bash, Java, Julia. Which
> of these languages offer non-blocking keyboard input as a standard part of the
> language?

That doesn't surprise me either. Even implementation languages such as C 
tend to shy away from the issue. And since C was intimately associated 
with Unix, it starts to get even less surprising!

But I seem to remember in a previous thread that Python had some problem 
even with line-buffered input. Something to do with only getting a line 
of input as a string then needed to do some processing to read 
individual elements, IIRC.

(FWIW my own language does strive to have this basic stuff built it. But 
getting full keyboard and console handling working as I want it across 
both Windows and Linux is challenging. It's a bit easier on Windows as, 
even though you're using a console, you have the full resources of the 
Win32 API to draw on.

On Linux you can't assume any such resources except some apparently 
1970s-style terminal handling, from what I can figure out.)

> Python has no "peek" and "poke" memory access commands either. It's not 1972
> and programming has moved on. The utility of something like this feature is
> very low, the amount of effort needed for a cross-platform solution is very
> high.

My language:

function peek(p,t=byte)=
     return makeref(p,t)^
end
...
print peek(0x400'000)

It 'works' on both Windows and Linux, although you need to know what 
addresses to safely peek. (I didn't try poke but that's also easy, if 
more dangerous. But usually I use such pointer accesses for known data 
structures and memory blocks.)

On a machine with a certain memory-mapped device, then this would be ideal.

-- 
Bartc