Nick Coghlan added the comment: 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(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29645> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
