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

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

  6. Search for "class TestCase".

  7. 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