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

[Steve D'Aprano]

On Sat, 29 Oct 2016 10:53 pm, BartC wrote:

> On 29/10/2016 02:04, Steve D'Aprano wrote:
>> On Fri, 28 Oct 2016 05:09 am, BartC wrote:
> 
>>> For years I've had discussions in comp.lang.c about things that C should
>>> or should not have.
> 
>> 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,
> 
> C is a supposedly ultra-portable and apparently simple language. 

I'm not sure if C *ever* was simple, but it certainly hasn't been simple for
the last quarter of a century.

The most recent version of the standard has a draft of 701 pages:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

The draft for the previous standard, C99, was 552 pages:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

See also:

http://www.open-std.org/jtc1/sc22/wg14/www/standards
http://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents


Here's a draft of ANSI C (C89):

http://flash-gordon.me.uk/ansi.c.txt

My browser formats that to 290 pages. So even in 1989, C was significantly
complex.



[...]
> The language and the way it's used have a few problems - why shouldn't
> someone talk about them?

Nobody is stopping you from discussing C's problems in the appropriate
forum. But unlike you and your hand-made compilers, with a user-base of
exactly 1 user (you), there are dozens of implementations of C, with tens
of thousands of users or more, and an ISO standard defining what is and
isn't C.


>   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.
> 
> Most of the enhancements I talked about were trivial. The language is
> unlikely to change because of me but it would be nice for someone to
> acknowledge them rather than defend one of C's crazy quirks or lack of a
> feature to the death.

You won't get any defence of C's crazy quirks from me.

[...]
> But I'd like to see Python running on a 64KB system
> (Micropython doesn't count!).

Hmmm. So tell me... how do you expect Python to run on tiny systems by
*adding* new features?

Regardless of how "small" this feature is, it is not negative size. The
implementation is at least 1 byte. The documentation is at least 1 byte.
The tests are at least 1 byte. If you think Python is too big now, then
adding this feature will make it at least 3 bytes bigger.


>>> 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.
> 
> 'read a,b,c' is weird and unintuitive compared with its counterpart
> 'print a,b,c'. OK....

print as a statement was always an anomaly, and yes, it got pretty weird:

print >>sys.stderr, spam, eggs

So much nicer now that it is a function that takes proper keyword arguments.

In any case, I wasn't specifically talking about 

    read a, b, c

Yes, it is a bit (actually a lot) unusual to assign a value to a variable by
way of a statement other than assignment, it is not unprecedented in
Python. We have at least three other binding statements:

    import name

    for name in ...

    del name


even though one of them is actually an *unbinding* statement. What I said
looked weird was your syntax:

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


If you're going to introduce special syntax for types, why make the types
strings rather than symbols?


> BTW what does reading three integers from the user look like in Python?

for i in range(3):
    n = int(input(""))


You want a prompt? Change the empty string to your prompt.

You want to assign to three different variables? Unroll the loop:

n = int(input(""))
p = int(input(""))
q = int(input(""))


If the user types something that isn't an integer, you want to try again?
Write a loop. If you're sensible, of course you will put it into a helper
function:


_SENTINEL = object()

def read_int_with_all_the_trimmings(
        prompt1='Enter an int: ',
        prompt2='Invalid value for an int; please try again: ',
        prompt3='Value out of range; please try again: ',
        max_times=2**31,
        low=None,
        high=None,
        default=_SENTINEL):
    msg = prompt1
    for attempt in range(max_times):
        s = input(msg)
        try:
            n = int(s)
        except ValueError:
            msg = prompt2
        else:
            out_of_range = (low is not None and n < low) or (
                            high is not None and n > high)
            if out_of_range:
                msg = prompt3
            else:
                return n
    if default is _SENTINEL:
        raise ValueError('not a valid int')
    return default




Does your `read` statement do all that? Why not?



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