[Python-Dev] patch for review: unittest ImportError handling

Chris Jerdonek chris.jerdonek at gmail.com
Wed Apr 14 14:31:44 CEST 2010


On Wed, Apr 14, 2010 at 4:12 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 14/04/2010 12:54, Chris Jerdonek wrote:
>>
>> On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
>> <fuzzyman at voidspace.org.uk>  wrote:
>>
>>>
>>> I'm still not convinced that this isn't a backwards incompatible change -
>>> up
>>> until now, however horrible it may be, TestLoader.loadTestsFromName only
>>> raised an AttributeError when it failed to load a test. Changing it to
>>> allow
>>> it propagate ImportError means that code catching errors by handling
>>> AttributeError will be potentially broken by the fix. I'm certainly happy
>>> to
>>> discuss this here though.
>>>
>>
>> Thanks for your response. Michael.  To understand your position
>> better, would you view changing the AttributeError in *any* way an
>> incompatible change (e.g. changing just the error message), or is it
>> only changing the error type that you view as backwards incompatible?
>>
>> The reason I ask is that I think it's the change in what the error
>> contains (e.g. the error message and stack trace) that is the more
>> important part of this change -- rather than whether that information
>> be wrapped in an ImportError versus an AttributeError.  It is the
>> information rather than the particular error type that will assist an
>> end-developer in diagnosing future unit-test failures.
>>
>
> Changing the error message to provide more useful information, possibly
> including the original traceback, would certainly avoid the potential for
> incompatibility. I'd be interested in seeing what other folks here on
> python-dev think.
>
>>
>>>
>>> An alternative fix would be for a new API and deprecation of
>>> loadTestFromName. A new API could return a placeholder test that raises
>>> the
>>> original error when run - that way individual errors don't break the test
>>> collection phase but are still reported. This *could* be added to
>>> loadTestsFromName with an optional argument.
>>>
>>
>> I'm not opposed to adding a new API, but I think it would be valuable
>> if we could find a way for people to enjoy the benefit of not having
>> the stack trace swallowed -- without having to change their code.
>
> It's a double edged sword though - it means existing users depending on the
> fact that this API only raises AttributeError have to change *their* code.
>
> For a new API I like Rob Collin's suggestion of a keyword argument to
> loadTestsFromNames that returns an error placeholder instead of raising an
> exception. That couldn't be put into 2.7 now though.
>
>> I'm
>> currently part of a project where the current behavior makes it harder
>> to track down unit test failures.  I imagine many developers are in a
>> similar situation.  This seems to be a bug, and such developers may be
>> in a position where they can't change how their unit tests are run,
>> but they're nevertheless stuck diagnosing the failures.
>>
>> I'm writing on the assumption that there is a way to preserve the
>> stack trace and error message of an ImportError while re-raising it as
>> an AttributeError.
>>
>>
>
> The original stacktrace could be included as part of the error message.
> Pretty horrible though.

I just experimented with this myself.  Couldn't we do something like
the following to change the error type and preserve the stack trace --
without including the stack trace as part of the message?

try:
    foo()
except ImportError:
    excType, excValue, excTraceback = sys.exc_info()
    raise AttributeError, excValue, excTraceback

Superficially this seems to have the desired effect.  We could also
adjust the error text to indicate that the AttributeError was
originally an ImportError.

The above is similar to the code you referenced in one of your
comments to issue 7559--

http://twistedmatrix.com/trac/browser/trunk/twisted/python/reflect.py?rev=28196#L384

--Chris


More information about the Python-Dev mailing list