On Tue, Nov 2, 2010 at 6:58 PM, Guido van Rossum <gu...@python.org> wrote: .. > To spout a somewhat contrarian opinion, I just browsed the new > unittest package, and the structure seems reasonable to me, even if > its submodules are not particularly reusable. I've used this kind of > style for development myself. What is so offensive about it?
I would not call it "offensive", but what I find annoying is >>> import unittest >>> unittest.TestCase.__module__ 'unittest.case' This may not be a problem for smart tools, but for me and a simple editor what used to be: Let's find code for unittest.TestCase. 1. Open Lib/unittest.py. 2. Search for "class TestCase". is now 1. Open Lib/unittest.py -> No such file or directory. 2. OK, I'm in 2.7. Open Lib/unittest/__init__.py 3. Search for "class TestCase" -> beep 4. OK, search for "TestCase" -> from .case import (TestCase, FunctionTestCase, SkipTest, skip, skipIf, .. 5. Hmm, what is ".case". Ah, the relative import - open case.py 7. Search for "class TestCase". 8. What exactly was I looking for? The above is only slightly exaggerated scenario that I went through several times when I started using 2.7 before I conditioned myself to grep in Lib/unittest/*.py. What is unfortunate is that file split was accompanied by an explosion of assert* methods in TestCase API which means that anyone reading 2.7 unittests is likely to encounter an unfamiliar method that has to be looked up. I think the problem that I described is just a slightly reworded problem that Raymond reported at the beginning of this thread. In other words, I am not alone in seeing this as a problem. PS: For a "made from scratch" API I would prefer TestCase only be available from unittest.case. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
