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

Brett Cannon brett at python.org
Wed Nov 3 00:00:40 CET 2010

On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:

On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:

I think the issue here is that the file structure of the code no longer matches the public API documented by unittest. Personally I, like most people it seems, prefer source files to be structured in a way to match the public API. In the case of unittest Michael didn't. He did ask python-dev if it was okay to do what he did, we all kept quiet, and now we have realized that most of us prefer to have files that mirror the API; lesson learned. But Python 2.7 shipped with this file layout so we have to stick with it lest we break any imports out there that use the package-like file structure Michael went with (which we could actually document and use if we wanted now that Michael has already broken things up). Reversing the trend by sticking all the code into unittest/init.py and then sticking import shims into the existing modules would be a stupid waste of time, especially considering the head maintainer of the package likes it the way it is. I'm not sure I follow where we're stuck with the current package. AFAICT, the module is still used with "import unittest".

Yes, as far as you can tell, but who the hell knows what someone is doing with code you are not aware of. As I said, Python 2.7 shipped with the code structured like this, so it's possible someone is importing unittest.case.TestCase instead of unittest.TestCase.

The file splitting was done badly, so I don't think there any of the components are usable directly, i.e. "from unitest.case import SkipTest".

I wouldn't say it was done badly, just non-standard. I was able to figure out where all the key classes were based on the file names. I personally would have no trouble doing from unittest.case import TestCase if more test case classes came along for various needs.

Also, I don't think the package structure was documented or announced.

Announced publicly? No, not that I know of.

This is in contrast to the logging module which does have a clean separation of components and where it isn't unusual to import just part of the package. What is it you're seeing as a risk that I'm not seeing?

Broken imports between Python 2.7 code and any version of Python where unittest is re-merged back into a single module.

Are we permanently locked into the exact ten filenames that are currently used:  utils, suite, loader, case, result, main, signals, etc? Is the file structure now frozen?

Somewhat, yes. Screwing with unittest is always touchy as absolutely no one wants their tests to break, and that includes messing with imports. We could stick in import shims to shift everything into unittest/init.py, but the benefits you have outlined already don't strike me as not worth the hassle especially since you won't ever get your unittest.py format back.

More information about the Python-Dev mailing list