Author gvanrossum
Recipients davin, gvanrossum, rhettinger, scop
Date 2016-08-31.18:31:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJ+Q_nmhG76W7cWdixrLuZP=uk39yCGHhZ4On9t=GiOG4Q@mail.gmail.com>
In-reply-to <1472667766.22.0.279097392675.issue27916@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2016-08-31 18:31:52gvanrossumsetrecipients: + gvanrossum, rhettinger, scop, davin
2016-08-31 18:31:52gvanrossumlinkissue27916 messages
2016-08-31 18:31:52gvanrossumcreate