On Jun 19, 2012, at 7:43 AM, Vladimir Perić wrote:
> there are basically two strategies:
> maintaining py2 code and using 2to3 when installing under py3, or
> maintaining a codebase which is compatible with both 2 and 3
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.
> As such, I would like to request permission for the coverage
> requirements to be relaxed for specific Python 3 changes. As mentioned
> above, this would allow me to progress much faster and concentrate on
> the bigger incompatibilities. Of course, I would still write tests for
> more complex code, if and where required.
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.
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).
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.)
I guess this does represent some relaxation of the testing policy, since for a
real functional change I probably wouldn't accept a test quite 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.
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 ;-).
-glyph
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
