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
threading.Timer.__init__() should use immutable argument defaults for args and kwargs #61637
Comments
The __init__() method of threading.Timer uses *mutable* default values for the "args" and "kwargs" arguments. Since the default argument objects are created once and re-used for each instance, this means that changing the args list or kwargs dict of a Timer object that used the argument defaults will specify those arguments to all future Timer objects that use the defaults too. def __init__(self, interval, function, args=[], kwargs={}): A fully backwards-compatible way to fix this is to instead use None as the default value for args and kwargs and just create a new list and/or dict inside __init__() if they are None. That way each new instance of Timer will get its very own args list and kwargs dict object. def __init__(self, interval, function, args=None, kwargs=None):
...
self.args = args if args is not None else []
self.kwargs = kwargs if kwargs is not None else {} Here is a sample script that reproduces the issue: import threading
event = threading.Event()
def func(*args, **kwargs):
print("args={!r} kwargs={!r}".format(args, kwargs))
event.set()
timer1 = threading.Timer(1, func)
timer1.args.append("blah")
timer1.kwargs["foo"] = "bar"
timer2 = threading.Timer(1, func)
timer2.start()
event.wait() Here is the example output when run before the fix: c:\dev\cpython>PCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py And after the fix: c:\dev\cpython>PCbuild\python_d.exe ThreadingTimerInitDefaultArgsIssueDemo.py As you can see, in the version without the fix, the elements added to timer1's args and kwargs were also given to timer2, which is almost certainly not what a user would expect. A proposed patch, ThreadingTimerInitDefaultArgsIssueDemo.01.patch, is attached. This fixes the issue, updates the docs, and adds a unit test. |
Hmm. This wasn't an issue before 3.3 because previously one couldn't subclass Timer. So yeah, this needs to be fixed, but only in 3.3 and tip. Thanks for the patch. |
Thanks r.david.murray for your feedback. Although I disagree with your conclusion that this does not affect 2.7. Just try running the "sample script that reproduces the issue" from my first post and you will see the erroneous behaviour in 2.7. Even though threading.Timer is a function in 2.7 (instead of a class), it still ultimately returns a class whose args and kwargs members can be modified. |
I'm sorry, you are correct. I replied too quickly without thinking it through. |
Thanks r.david.murray. I appreciate you taking the time to look at this issue! |
The reported behavior is not a bug by our usual standards. The code is exactly as documented. Threading is not a beginner module. Any competent Python programmer who reads either of the above, or the code line you quoted, would expect exactly the behavior you report. I think we should presume that people who monkey-patch the class, which is an unusual thing to do, know what they are doing. The patch would break any such intentional usage. If the signature were to be changed, there should be a deprecation period first, preferably with a DeprecationWarning for mutation either through an instance or through .__init__. I do not see anything special about this particular function. If we change this use of [] and {} as defaults, then we should look at all such uses in the stdlib -- after pydev discussion. But I currently think we should leave well enough alone. The Timer class was added in Sept. 2001, rev 19727, issue bpo-428326. The patch was written by Itamar Shtull-Trauring, approved by Guido, and reviewed and committed by Martin. |
I agree with the OP -- it's a simple fix and the current code definitely violates our recommendations. I see no reason not to submit this (if there's nothing *else* wrong with it -- it actually seems pretty complete). Not sure how important it is to fix in 2.7, but I don't see a problem with it either. |
New changeset 2698920eadcd by R David Murray in branch '3.3': New changeset 8c15e57830dd by R David Murray in branch 'default': |
Thanks, Denver. I'm choosing not to backport it to 2.7, but that can be done later if someone finds it worth doing. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: