This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author michael.foord
Recipients ezio.melotti, michael.foord, pitrou, rhettinger
Date 2010-11-01.03:32:31
SpamBayes Score 8.123668e-12
Marked as misclassified No
Message-id <1288582354.76.0.203918274668.issue10273@psf.upfronthosting.co.za>
In-reply-to
Content
In general *none* of this should be done until there is clear consensus on Python-dev and it isn't clear that this is the case.

* On the deocumenting: barry warsaw objects to public apis that aren't documented and gregory smith asserts (natch) that it *can* be useful to call these methods directly for the explicit type checking they do. Let's see how this discussion pans out.

* For the greater / less comparison methods (etc) they would have to be new names as Python 2.7, 3.1 and unittest2 have the old names. This makes the TestCase even *bigger*. Let's see if we can get any consensus on this on Python-dev. Like Antoine I prefer assertRegex to assertRegexp.

* Note that assertItemsEqual is not new in 3.2 it is new in 2.7. If we remove it we make porting code using Python 2.7 (or earlier with unittest2) unnecessarily hard. The functionality is still useful but I agree that making the slow path more efficient would be good.

* Recombining the package into a single file *will not* happen without a BDFL pronouncement. unittest is massively easier to maintain now.

* Review the camel casing on assertIsInstance - isn't this just bike shedding?
History
Date User Action Args
2010-11-01 03:32:34michael.foordsetrecipients: + michael.foord, rhettinger, pitrou, ezio.melotti
2010-11-01 03:32:34michael.foordsetmessageid: <1288582354.76.0.203918274668.issue10273@psf.upfronthosting.co.za>
2010-11-01 03:32:33michael.foordlinkissue10273 messages
2010-11-01 03:32:31michael.foordcreate