Guido van Rossum added the comment: I mostly adhere to the rule of thumb "if it ain't broke, don't fix it". So I would only endorse such changes if they address actual pain, rather than possible pain.
Note that that rule of thumb was born out of worry about another possible pain: the observation that some fraction of well-intentioned fixes actually break something unanticipated. An (imagined) example in this case: if someone mocks time.time() in a unit test, your fix *might* break their test. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27916> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
