classification
Title: Python Interpreter Doesn't Work Well In Thread Class
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: SilentGhost, docs@python, mark.dickinson, paul.moore, pitrou, steve.dower, tim.golden, zach.ware, 임수진학부생
Priority: normal Keywords:

Created on 2020-02-08 09:55 by 임수진학부생, last changed 2020-02-08 10:24 by SilentGhost. This issue is now closed.

Messages (3)
msg361622 - (view) Author: 임수진학부생 (임수진학부생) Date: 2020-02-08 09:55
================================================================
import threading
import time

def threadFunc():
    while True:
        print('new thread')
        time.sleep(2)
def main():
    th = threading.Thread(target=threadFunc())
    th.start()
    while True:
       print('main Thread')
       time.sleep(1)
    th.join()
 
if __name__ == '__main__':
   main()
==============================================================

When I run the above code in python 3.7, it works in unexpected way.

I expected this code causes an syntax error for giving an improper argument to parameter because I gave "threaFunc()" not "threaFun" as an argument of target in Thread class. However, this code executes a function "threadFunc()" as a general function not thread.
msg361623 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2020-02-08 10:14
There's no other reasonable way for Python to work here. It *is* an error to pass something that's not a callable as a thread "target", but it's a coding error that can only be detected at runtime, not a syntax error that can be detected statically before the code executes.

And because threadFunc() never returns, Python never gets the opportunity to check the arguments to threading.Thread: the arguments to a function call have to be evaluated before that function call can be made.

It is a fairly common error, though, and it might be possible for a linter to flag this error (though probably with a smattering of false positives and false negatives). That's out of scope for Python itself.
msg361624 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2020-02-08 10:23
SyntaxError is produced when there is a syntax problem in the code to be executed, this code is fine from the syntax perspective, so this particular error would not be raised.

It is also perfectly fine to have a function call where you have it, the only thing one would need to observe is that the returned value is a callable (or None which would be return value in your case had your function terminated). Perhaps there is an improvement to be made in documentation by way of giving an example, but the solution you're suggesting is not feasible.
History
Date User Action Args
2020-02-08 10:24:08SilentGhostsetstatus: open -> closed
nosy: + mark.dickinson

resolution: not a bug
stage: resolved
2020-02-08 10:23:15SilentGhostsetstatus: closed -> open

assignee: docs@python
components: + Documentation, - Windows

nosy: + pitrou, SilentGhost, docs@python, - mark.dickinson
messages: + msg361624
resolution: not a bug -> (no value)
stage: resolved -> (no value)
2020-02-08 10:14:31mark.dickinsonsetstatus: open -> closed

nosy: + mark.dickinson
messages: + msg361623

resolution: not a bug
stage: resolved
2020-02-08 09:55:36임수진학부생create