Terry J. Reedy added the comment:
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.
----------
nosy: +ezio.melotti, rhettinger, terry.reedy
stage: -> test needed
type: -> enhancement
versions: +Python 3.5, Python 3.6
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue24641>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
