1

In Python, in what way can I do something on loop while user has not given an input. I have python client and I ask for user input, but while user has not given an input I'd like to keep giving updates every five second.

I can't use

 while (raw_input==""):
      update()

since if input is "", it means user already entered something (hit enter);

Is there a way to do it?

UPDATE:

I still can't get anything to work for me. I tried the method below, also tried something similar to this thread: waiting for user input in separate thread. And I also tried instead passing an update() method to the thread that's supposed to be working in the background. But anything with raw_input() makes it stuck on waiting for input:

 import threading
 import time

def update():
   while True:
      time.sleep(5)
      print "update"+'\n'

mythread = threading.Thread(target=update, args=())
mythread.daemon = True
mythread.start()

while True:
   usrin=raw_input()
   print "you typed: "+usrin

Every time user inputs something, update is done and then usrin is given back. If this was what I wanted I could just easily put the update() into the last while loop.

If I were to just start this thread with update method and do nothing else in the program (scrap the last while loop), then in shell while it updates every five seconds I can still use the shell (i.e type 3+5 and it gives me 8). I want something like that to happen within the program, when user is inactive update, and if he types react and go back to updating.

NOTE: Also, I'm currently using python 2.7.8, would switching versions help?

Community
  • 1
  • 1
Sunny
  • 605
  • 10
  • 35

1 Answers1

1

Maybe this can get you started:

from threading import Thread
from time import sleep

result = None

def update_every_second():
    while result is None:
        sleep(1)
        print "update"

t = Thread(target=update_every_second)
t.start()
result = raw_input('? ')

print "The user typed", result
jacg
  • 2,040
  • 1
  • 14
  • 27
  • Generally speaking, resources (like data) shared between threads should use some sort of mechanism to prevent simultaneous access. – martineau Oct 10 '14 at 22:48
  • @martineau Is the GIL not enough in this case? – jacg Oct 10 '14 at 22:57
  • First of all the GIL (Global Interpreter Lock), which prevents more than one thread from running at a time, is a C Python implementation detail, not all Pythons have one. Plus, my understanding is that it is released on I/0. Even CPU-bound threads that never do any I/O do a release and reacquire the GIL every once in a while which gives other threads a chance to run. – martineau Oct 11 '14 at 12:46
  • @martineau I'm not sure what your point is. The only shared resource in the above example is the binding of the name `result`: it is rebound by the main thread and it is read by the other thread. One reader, one writer, and the writer performs what should be an atomic operation on *any* Python implementation (one rebinding). The reader performs an LGB lookup which is found in G. Given that the L part of LGB is resolved at compile time, that lookup is probably (effectively) atomic on any implementation too. How would you improve the thread safety of the above code sample? Do you need to? – jacg Oct 11 '14 at 13:15
  • Simply put, `result` is in a indeterminate state while `raw_input()` is reading a line from input waiting for a newline while accumulating characters read into a string -- so you don't want the other thread checking its value at the same time. BTW, it's commonly referred to as the [LEGB](http://stackoverflow.com/a/292502/355230) scoping rule. – martineau Oct 11 '14 at 18:13
  • As long as `raw_inuput()` 'is reading a line from input waiting for a newline ...', the value of `result` is not being affected in any way whatsoever. Once `raw_input()` has created an object, it returns that object and that object is then (and only then) bound to the name `result`. The only potential race is whether the other thread looks up the name `result` before or after the name is rebound to the result returned by `raw_input()` because both the binding and the lookup are atomic. As we don't really care if we loop one more time, there is no problem. – jacg Oct 11 '14 at 22:11