<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 19, 2012, at 7:43 AM, Vladimir Perić wrote:</div><div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="font-family: monospace; ">there are basically two strategies:<br>maintaining py2 code and using 2to3 when installing under py3, or<br>maintaining a codebase which is compatible with both 2 and 3</span></blockquote><br></div><div>Based on the experiences of other porters I have talked to, and heard speaking on mailing lists, 2to3 still has yet to live up to its promise, and a unified codebase is much more manageable. That said, there are syntax changes ('except...as...' being the big one) that make supporting 2.5->3 difficult, and only becomes reasonable at 2.6->3. So it may be necessary to get 2to3 involved for some fixers.</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Menlo; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">As such, I would like to request permission for the coverage<br>requirements to be relaxed for specific Python 3 changes. As mentioned<br>above, this would allow me to progress much faster and concentrate on<br>the bigger incompatibilities. Of course, I would still write tests for<br>more complex code, if and where required.<span class="Apple-converted-space"> </span></span></span></blockquote></div><br><div>History teaches us that "simple" or "trivial" changes which allegedly don't require tests because they are "so obvious" are pretty much always going to introduce critical bugs. I like the idea of finding ways to avoid testing defunct code like what Itamar proposes, but a blanket exception to the testing policy is not acceptable to me.</div><div><br></div><div>That said, you don't have to write particularly awesome or thorough tests. Any line of code can be reached by satisfying its dependencies and calling the function it's in. So, if you need to, write trivial fakes or build on Twisted's existing library of test doubles (e.g. proto_helpers).</div><div><br></div><div>For example, let's say you're changing a method on a class whose initializer takes 30 arguments and all of them involve library objects from some heinously complex 3rd-party library with thousands of functions in it. You don't need to actually make a "real" instance of the class, if it's just that one method which needs modification. Write a test subclass which only works for that method, or even just suck out the im_func attribute and pass it a different 'self'. (Oops! Python 3 changes everything so you have to write a utility which converts a method-or-function into a function in a version-dependent way first. But you get the idea.)</div><div><br></div><div>I guess this does represent <i>some</i> relaxation of the testing policy, since for a real functional change I probably wouldn't accept a test <i>quite</i> as gross as what I just described... but in this case, we're just trying to make sure the code still runs in both cases.</div><div><br></div><div>If this seems like more work than you signed up for... well, congratulations, this internship is providing you with a realistic view of professional software development ;-).</div><div><br></div><div>-glyph</div><div><br></div></body></html>