Why doesn't Python include non-blocking keyboard input function?
Steve D'Aprano
steve+python at pearwood.info
Sat Oct 29 10:19:20 EDT 2016
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.
More information about the Python-list
mailing list