A typical TypeError message use the following pattern:
  TypeError: 'int' object is not callable
as it is the class, not the value, that is the problem.

If the same is always true for the JSON TypeError, at the point of failure, then the dumps message could follow the same pattern.

However, I don't know if the message *is* value independent.  The SO question asked about

TypeError: {'album': [u"Rooney's Lost Album"], 'title': [u'The Kids
After Sunset'], 'artist': [u'Rooney']} is not JSON serializable

and the OP claimed in a comment to the accepted answer that the problem was that the value objects represented as lists were not list() objects, just as '5' here is not an int() object.

The JSON error code, in 3.5 at

  File "C:\Programs\Python35\lib\json\encoder.py", line 180, in default
    raise TypeError(repr(o) + " is not JSON serializable")

could be expanded to check whether the string representation starts with the class name and if it does not, add "'classname' object" at the front. This would solve Madison's posted issue, but not the SO problem.
(It would, however, have made it clear that the {}s represented a real dict() object and directed attention inward.)

For testing, compile('','','exec') returns an object that cannot be dumped.

To me, this looks more like an enhancement than bugfix, so a change might be limited to future releases.