[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/email/test test_email_codecs.py,1.1,1.2

[Tim Peters]

[Barry]
> A better fix, IMO, is to recognize that the `test' package has become
> a full fledged standard lib package (a Good Thing, IMO), heed our own
> admonitions not to do relative imports, and change the various places
> in the test suite that "import test_support" (or equiv) to "import
> test.test_support" (or equiv).
>
> I've twiddled the test suite to do things this way, and all the
> (expected Linux) tests pass, so I'd like to commit these changes.
> Unit test writers need to remember to use test.test_support instead of
> just test_support.  We could do something wacky like remove '' from
> sys.path if we really cared about enforcing this.  It would also be
> good for folks on other systems to make sure I haven't missed a
> module.

Note test/README, which says in part:

"""
NOTE:  Always import something from test_support like so:

    from test_support import verbose

or like so:

    import test_support
    ... use test_support.verbose in the code ...

Never import anything from test_support like this:

    from test.test_support import verbose

"test" is a package already, so can refer to modules it contains without
"test." qualification.  If you do an explicit "test.xxx" qualification, that
can fool Python into believing test.xxx is a module distinct from the xxx
in the current package, and you can end up importing two distinct copies of
xxx.  This is especially bad if xxx=test_support, as regrtest.py can (and
routinely does) overwrite its "verbose" and "use_large_resources"
attributes:  if you get a second copy of test_support loaded, it may not
have the same values for those as regrtest intended.
"""

I don't have a deep understanding of these miserable issues, so settled for
a one-line patch that worked.  The admonition to never import from
test.test_support was a BDFL Pronouncement at the time.

Note that Jack runs tests in ways nobody else does, via importing something
or other from an interactive Python session (Mac Classic doesn't have a
cmdline shell -- something like that).  It's always an adventure trying to
guess how things will break for him, although I'm not sure your suggestion
is (or isn't) relevant to Jack.

I imagine things will work provided that all imports "are the same".  I'm
not sure fiddling all the code is worth it just to save a line of typing in
the email package's test suite.