>> 1. How the unittests will be integrated: there is 1 socket unittest
>> module ported from cpython 2.4, and 3 select test modules, A: the
>> cpython test_select.py module (which does not integrate into an unittest
>> framework), B: the latter module rewritten by me to integrate with
>> unittest, and C: a new unittest-based module which has much wider
>> coverage of the select API.
> Where is C coming from? How do the coverage of B and C overlap? It
> sounds like we should just check B into Jython's Lib/test and it'll
> cover up CPython's version, but I'm not sure where C fits in with all
> of that.
B is essentially the same as A, but rewritten to use the unittest
framework. B and C are completely distinct modules, with completely
A (i.e. the original cpython select test module) has *very* poor
coverage, so I wrote a brand new module which has *much* more extensive
coverage: it is the "C" module referred to above. It runs and passes on
cpython 2.4 as well as jython; I consider it an important part of the
checkin, and hope that it might find its way into cpython as well.
So if anything should be dropped from the checkin, it should be the
original cpython test_select.py (A): it serves no purpose other than to
illustrate where B came from.
> There's no need to support 1.3. We went to 1.4.2 for 2.2 when it came
> up that everything prior to that has been EOL'd by Sun.
> If you go ahead and commit on 2.3, I'll take a look at #3 for both 2.3
> and trunk. I'm all for getting it in on 2.3. The branch is in raw
> enough shape that I don't think anyone is running off of it, so having
> a slightly broken socket and select won't cause pain.
I see no reason why it can't be checked into 2.3 after a couple of days
review in the sandbox? I'm all for getting the new stuff into 2.2 and
2.3 as well: I am just not comfortable doing a major module upgrade on
my very first checkin :-)