Multi-threading with a simple timer?

[Michael Vilain]

The way I've done the "input with timeout" requirement the OP requested is dependent on the operating system.  The current implementation of the input function doesn't offer that feature.

https://docs.python.org/3/library/functions.html#input

In another language, I used low-levelsystem calls to the OS to get terminal assigned to the process running the program, open the terminal for read, and set a time-out for that read.  This is by no means portable.

I looked at the os.open() method and it doesn't offer a timeout option.  Then I found curses.  That has a getch() function that can be setup with a halfdelay() timer.

https://docs.python.org/3/howto/curses.html

That's the closest I could find to getting input with a time-out from the terminal.  If it's to kludgy, you'll have to roll your own OS-specific version.  My guess is that Windows and Linux (and whatever else you choose to implement) are different.

Got code?

--
Anything invented before you were eighteen was there all along.
Anything invented before you’re thirty is exciting and will change the world forever.
Anything invented after that is an abomination and should be banned. -- Cory Doctorow



> On 03-Jul-2018, at 8:21 AM 🌞, Chris Angelico <rosuav at gmail.com> wrote:
> 
> On Wed, Jul 4, 2018 at 12:05 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Gregory Ewing <greg.ewing at canterbury.ac.nz>:
>> 
>>> Robin Becker wrote:
>>>> if I leave out the signal.signal(signal.SIGALRM,signal.SIG_IGN) then
>>>> the timeout function gets called anyway.
>>> 
>>> Yes, it needs some more stuff around it to make it useful. Probably
>>> you also want the signal handler to raise an exception and catch it
>>> somewhere rather than exiting the process.
>> 
>> My advice: stay away from (non-terminal) signals. They are a primitive
>> communication scheme that *might* have had uses in the early 1970's.
>> 
>> At the time signals were part of so-called "asynchronous programming."
>> The pattern called for the main routine to have:
>> 
>>    for (;;)
>>        pause()
>> 
>> and *everything* in the program was done in signal handlers.
>> 
>> Unless you do *everything* in signal handlers, you should do *nothing*
>> in signal handlers.
> 
> Yeah, signal handlers are utterly useless. You never want to use them
> to receive messages from the operating system in a process-independent
> way. The fact that it's possible to use them badly means that we
> should abolish them completely and never use them, like ever. It's not
> like they're a really effective way for you to be notified that you no
> longer have a controlling terminal, thus permitting you to decide
> whether to continue or terminate. It's not like they're a standard way
> for the user to say "please interrupt this operation", thus allowing
> you to cleanly break off what you're doing and return to the main
> loop. No, signal handlers are utterly useless, and only MIGHT have had
> uses forty years ago. They're completely and utterly outmoded by
> modern systems that use HTTP and XML to send easy-to-use messages
> between processes.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list