Improved Error Message for "Unhashable Type"
The error message for using a mutable sequence as a set item or map key seems to frequently confuse Python beginners. The current wording is:
{[1, 2, 3]: [4, 5, 6]} TypeError: unhashable type: 'list'
The first thing a Google search finds for "unhashable type" is ~4k Stack Overflow results like: https://stackoverflow.com/questions/13264511/typeerror-unhashable-type-dict The message does not include: * The type on which the operation is performed * Which input to the operation is the problem * The word "hashable" verbatim, which appears in the glossary * A link to https://docs.python.org/3/glossary.html#term-hashable * A suggestion of what to do instead For example: TypeError: dict keys must be hashable ( https://docs.python.org/glossary.html#term-hashable), 'list' is not. Consider using a primitive type (e.g. int, str) or immutable sequence (e.g. tuple, frozenset). (That could be too much stuff, my point is I think there's room for improvement over "unhashable type: 'list'".) I filed a bug about this (https://bugs.python.org/issue41114), but it was closed by a core contributor, who suggested discussing that on this list instead. While it's true that you can Google the error message and find the relevant information, I think the error message text would be worth improving. Peace, -Sam
28.09.20 16:31, Samuel Freilich via Python-ideas пише:
The code which raises TypeError does not know whether it was called internally by dict or set method or explicitly by hash(). So neither the type of container, nor operation are known. And it may be raised when the key is a tuple which contains a list, that contradicts the proposed error message.
On Mon, Sep 28, 2020 at 6:34 AM Samuel Freilich via Python-ideas < python-ideas@python.org> wrote:
The message does not include:
* The word "hashable" verbatim, which appears in the glossary
* A link to https://docs.python.org/3/glossary.html#term-hashable
That's a pretty good entry that does talk about the importance of hashability in dicts and sets. So making it easier to find might be enough to help here. So +1 on adding that link to the error message (if, in fact, links in error messages are on the table at all -- do any existing built in error message have links in them? and/or at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there. -CHB
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
The code which raises TypeError does not know whether it was called internally by dict or set method or explicitly by hash
It's true, but I don't think it would be too hard to preserve some of the context in some of those common cases. In that bug report, I suggested adding an optional parameter for the format string used to generate the error message to PyObject_Hash and PyObject_HashNotImplemented (but I haven't yet tried to sketch out a full code change). That doesn't fully cover the case where hash calls hash recursively, and obviously we wouldn't want to handle that in a way that potentially mucks with the performance of hash functions.
do any existing built in error message have links in them?
I don't think so, which is maybe a reason to avoid the inconsistency. I don't know whether that's the result of some intentional decision. I do think it can be useful to have more direct links to documentation, though.
at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there.
I think that's reasonable. On Mon, Sep 28, 2020 at 11:41 AM Christopher Barker <pythonchb@gmail.com> wrote:
28.09.20 16:31, Samuel Freilich via Python-ideas пише:
The code which raises TypeError does not know whether it was called internally by dict or set method or explicitly by hash(). So neither the type of container, nor operation are known. And it may be raised when the key is a tuple which contains a list, that contradicts the proposed error message.
On Mon, Sep 28, 2020 at 6:34 AM Samuel Freilich via Python-ideas < python-ideas@python.org> wrote:
The message does not include:
* The word "hashable" verbatim, which appears in the glossary
* A link to https://docs.python.org/3/glossary.html#term-hashable
That's a pretty good entry that does talk about the importance of hashability in dicts and sets. So making it easier to find might be enough to help here. So +1 on adding that link to the error message (if, in fact, links in error messages are on the table at all -- do any existing built in error message have links in them? and/or at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there. -CHB
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
The code which raises TypeError does not know whether it was called internally by dict or set method or explicitly by hash
It's true, but I don't think it would be too hard to preserve some of the context in some of those common cases. In that bug report, I suggested adding an optional parameter for the format string used to generate the error message to PyObject_Hash and PyObject_HashNotImplemented (but I haven't yet tried to sketch out a full code change). That doesn't fully cover the case where hash calls hash recursively, and obviously we wouldn't want to handle that in a way that potentially mucks with the performance of hash functions.
do any existing built in error message have links in them?
I don't think so, which is maybe a reason to avoid the inconsistency. I don't know whether that's the result of some intentional decision. I do think it can be useful to have more direct links to documentation, though.
at least add "unhashable" to the glossary -- after all, both "mutable" and "immutable" are in there.
I think that's reasonable. On Mon, Sep 28, 2020 at 11:41 AM Christopher Barker <pythonchb@gmail.com> wrote:
participants (3)
-
Christopher Barker -
Samuel Freilich -
Serhiy Storchaka