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
--
https://mail.python.org/mailman/listinfo/python-list
