MutaFix run: boltons-001

tests/test_tbutils.py::test_contextual

E   AssertionError: assert 'builtins.Exc...c_a exception' == 'Exception: func_a exception'
E     
E     - Exception: func_a exception
E     + builtins.Exception: func_a exception
E     ? +++++++++

1. boltons/tbutils.py::ContextualCallpoint.to_dict call depth 1 · Ochiai 1.00 (failing 1, passing 0)
2. boltons/tbutils.py::ExceptionInfo.get_formatted call depth 1 · Ochiai 1.00 (failing 1, passing 0)
3. boltons/tbutils.py::ContextualCallpoint.__init__ call depth 1 · Ochiai 1.00 (failing 1, passing 0)
4. boltons/tbutils.py::Callpoint.to_dict call depth 1 · Ochiai 1.00 (failing 1, passing 0)
5. boltons/tbutils.py::Callpoint.from_current call depth 1 · Ochiai 1.00 (failing 1, passing 0)
6. boltons/tbutils.py::ContextualCallpoint.from_frame call depth 2 · Ochiai 1.00 (failing 1, passing 0)
7. boltons/tbutils.py::Callpoint.from_frame call depth 2 · Ochiai 1.00 (failing 1, passing 0)
8. boltons/tbutils.py::_DeferredLine.__repr__ call depth 2 · Ochiai 1.00 (failing 1, passing 0)
9. boltons/tbutils.py::ContextualCallpoint._populate_local_reprs call depth 3 · Ochiai 1.00 (failing 1, passing 0)
10. boltons/tbutils.py::ContextualCallpoint._populate_context_lines call depth 3 · Ochiai 1.00 (failing 1, passing 0)
11. boltons/tbutils.py::ContextualCallpoint.from_tb call depth - · Ochiai 1.00 (failing 1, passing 0)
12. boltons/tbutils.py::Callpoint.__repr__ call depth - · Ochiai 1.00 (failing 1, passing 0)
13. boltons/tbutils.py::TracebackInfo.get_formatted call depth 1 · Ochiai 0.71 (failing 1, passing 1)
14. boltons/tbutils.py::ExceptionInfo.from_current call depth 1 · Ochiai 0.71 (failing 1, passing 1)
15. boltons/tbutils.py::ExceptionInfo.from_exc_info call depth 2 · Ochiai 0.71 (failing 1, passing 1)
16. boltons/tbutils.py::Callpoint.tb_frame_str call depth 2 · Ochiai 0.71 (failing 1, passing 1)
17. boltons/tbutils.py::ExceptionInfo.__init__ call depth 2 · Ochiai 0.71 (failing 1, passing 1)
18. boltons/tbutils.py::_DeferredLine.__str__ call depth 2 · Ochiai 0.71 (failing 1, passing 1)
19. boltons/tbutils.py::Callpoint.__init__ call depth 2 · Ochiai 0.71 (failing 1, passing 1)
20. boltons/tbutils.py::TracebackInfo.__init__ call depth 2 · Ochiai 0.71 (failing 1, passing 1)

We need to examine what self.exc_type actually is. It might be a string already? Let's look at ExceptionInfo class definition. We'll read candidate 14 maybe? Actually we have candidate 14: ExceptionInfo.from_current, but we need ExceptionInfo itself. Not listed yet. But we can infer: ExceptionInfo probably stores exc_type as a type (class) or as a string? The error says "'str' object has no attribute '__name__'", meaning self.exc_type is a string. So we cannot use __name__ on a string. Instead, if it's already a string representing the full name, we need to extract the last part after the last dot. Or perhaps we want just the class name without module. For builtins.Exception, the string is 'builtins.Exception', we want 'Exception'.

Alternatively, maybe exc_type is the actual type object, but then why would it be a string? Could be that in some contexts it's stored as string? Let's check the ExceptionInfo class. We'll read it.

But note: The test also passes in some cases? There were passing tests earlier? The candidate list shows some functions ran in 1/1 failing and 1/1 passing tests. That indicates there is at least one passing test. So the bug might be that sometimes exc_type is a type, sometimes a string? Unlikely.

Better to look at ExceptionInfo definition. Let's read the file around that area. We'll do a read for the file boltons/tbutils.py to see ExceptionInfo. But we can only read specific candidates? The action read can take a candidate number, which refers to a fu

We have seen that ExceptionInfo.__init__ stores exc_type as passed in. We need to know what is passed in from ExceptionInfo.from_current or from_exc_info.
 Let's look at those methods.

We need to see what sys.exc_info returns: (type, value, traceback). So exc_type is a type object (like Exception), not a string. Then why did our patch cause AttributeError? Because maybe sometimes exc_type is a string? But the error said: AttributeError: 'str' object has no attribute '__name__'. That indicates that in some case, self.exc_type is a string. However, looking at the test, they raise a plain Exception, so exc_type should be the built-in Exception class. Unless there's something else.

Wait, the error message from the test after our patch was:

E   Exception: func_a exception
E   AttributeError: 'str' object has no attribute '__name__'. Did you mean: '__ne__'?

That suggests that when we tried to access __name__ on self.exc_type, it was a string. But why would self.exc_type be a string? Let's check the ExceptionInfo.__init__ again: it sets self.exc_type = exc_type, where exc_type comes from sys.exc_info()[0], which is a class, not a string.

Unless there's another place where ExceptionInfo is instantiated with a string? Or maybe the test is also using some other code path? But the test uses ContextualExceptionInfo.from_current(), which eventually calls ExceptionInfo.from_current().

Let's look at ContextualExceptionInfo. We haven't seen that yet. It might be a subclass. Let's check if it overrides __init__ or something.

But we don't have it in the candidates list. However, we can read it if needed. But first, let's see the test again: it uses ContextualExceptionI

We have exhausted our reads. Let's think about the problem again.

From the error message:
  E   Exception: func_a exception
  E   AttributeError: 'str' object has no attribute '__name__'

This indicates that in the patched version, we tried to access `__name__` on a string. So `self.exc_type` is a string, not a type.

Looking at the `__init__` of ExceptionInfo (candidate 17), we see:
    self.exc_type = exc_type

And from `from_current` -> `from_exc_info` (which we haven't seen, but we know from the traceback that it uses `sys.exc_info()`).

In standard Python, `sys.exc_info()` returns a tuple: (type, value, traceback). The first element is the exception type (a class), not a string.

However, note that the test is using `ContextualExceptionInfo.from_current()`. We haven't looked at `ContextualExceptionInfo` because it wasn't in the candidates. But note that the test says:

    ctx_ei = ContextualExceptionInfo.from_current()

So we must consider that `ContextualExceptionInfo` might be a subclass of `ExceptionInfo` and might override something.

But wait, we don't have `ContextualExceptionInfo` in the candidates. However, note that the test imports from `boltons.tbutils` and we have been looking at `boltons/tbutils.py`. It's possible that `ContextualExceptionInfo` is defined in the same file.

Given that we have no more reads, we must rely on what we have.

Alternatively, let's look at the `ExceptionInfo.from_exc_info` method (candidate 15) even though we didn't get to read i