Message288566
Nice, this is much cleaner than the current approach!
The one thing I would suggest is a new test case that:
- asserts webbrowser._tryorder is None
- asserts webbrowser._browsers is empty
- calls webbrowser.get()
- asserts webbrowser._tryorder is non-empty
- asserts webbrowser._browsers is non-empty
I wouldn't worry about explicitly testing the thread safety. That's just a normal double-checked locking pattern, so I think code review is sufficient to address that - the only way for it to break is for something to go horribly wrong in threading.RLock(). |
|
Date |
User |
Action |
Args |
2017-02-25 14:52:10 | ncoghlan | set | recipients:
+ ncoghlan, serhiy.storchaka, louielu |
2017-02-25 14:52:10 | ncoghlan | set | messageid: <1488034330.74.0.151318685231.issue29645@psf.upfronthosting.co.za> |
2017-02-25 14:52:10 | ncoghlan | link | issue29645 messages |
2017-02-25 14:52:10 | ncoghlan | create | |
|