[Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Nov 3 16:26:18 CET 2010


On Tue, Nov 2, 2010 at 6:58 PM, Guido van Rossum <guido at 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.


More information about the Python-Dev mailing list