Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python Interpreter Doesn't Work Well In Thread Class #83762

Closed
ghost opened this issue Feb 8, 2020 · 3 comments
Closed

Python Interpreter Doesn't Work Well In Thread Class #83762

ghost opened this issue Feb 8, 2020 · 3 comments
Labels
3.7 (EOL) end of life docs Documentation in the Doc dir type-bug An unexpected behavior, bug, or error

Comments

@ghost
Copy link

ghost commented Feb 8, 2020

BPO 39581
Nosy @pfmoore, @mdickinson, @pitrou, @tjguk, @zware, @zooba

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-02-08.10:24:08.516>
created_at = <Date 2020-02-08.09:55:36.527>
labels = ['invalid', 'type-bug', '3.7', 'docs']
title = "Python Interpreter Doesn't Work Well In Thread Class"
updated_at = <Date 2020-02-08.10:24:08.515>
user = None

bugs.python.org fields:

activity = <Date 2020-02-08.10:24:08.515>
actor = 'SilentGhost'
assignee = 'docs@python'
closed = True
closed_date = <Date 2020-02-08.10:24:08.516>
closer = 'SilentGhost'
components = ['Documentation']
creation = <Date 2020-02-08.09:55:36.527>
creator = '\xec\x9e\x84\xec\x88\x98\xec\xa7\x84\xed\x95\x99\xeb\xb6\x80\xec\x83\x9d'
dependencies = []
files = []
hgrepos = []
issue_num = 39581
keywords = []
message_count = 3.0
messages = ['361622', '361623', '361624']
nosy_count = 9.0
nosy_names = ['paul.moore', 'mark.dickinson', 'pitrou', 'tim.golden', 'SilentGhost', 'docs@python', 'zach.ware', 'steve.dower', '\xec\x9e\x84\xec\x88\x98\xec\xa7\x84\xed\x95\x99\xeb\xb6\x80\xec\x83\x9d']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39581'
versions = ['Python 3.7']

@ghost
Copy link
Author

ghost commented Feb 8, 2020

================================================================

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.

Repository owner added OS-windows 3.7 (EOL) end of life type-bug An unexpected behavior, bug, or error labels Feb 8, 2020
@mdickinson
Copy link
Member

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.

@SilentGhost
Copy link
Mannequin

SilentGhost mannequin commented Feb 8, 2020

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.

@SilentGhost SilentGhost mannequin added docs Documentation in the Doc dir and removed OS-windows labels Feb 8, 2020
@SilentGhost SilentGhost mannequin reopened this Feb 8, 2020
@SilentGhost SilentGhost mannequin removed the invalid label Feb 8, 2020
@SilentGhost SilentGhost mannequin assigned docspython Feb 8, 2020
@SilentGhost SilentGhost mannequin added docs Documentation in the Doc dir and removed OS-windows labels Feb 8, 2020
@SilentGhost SilentGhost mannequin reopened this Feb 8, 2020
@SilentGhost SilentGhost mannequin removed the invalid label Feb 8, 2020
@SilentGhost SilentGhost mannequin assigned docspython Feb 8, 2020
@SilentGhost SilentGhost mannequin closed this as completed Feb 8, 2020
@SilentGhost SilentGhost mannequin added the invalid label Feb 8, 2020
@SilentGhost SilentGhost mannequin closed this as completed Feb 8, 2020
@SilentGhost SilentGhost mannequin added the invalid label Feb 8, 2020
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.7 (EOL) end of life docs Documentation in the Doc dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants