On 20 July 2013 09:47, Ethan Furman <ethan at stoneleaf.us> wrote:
> While working on issue #18508 I stumbled across this:
>
> Traceback (most recent call last):
> ...
> File "/usr/local/lib/python3.4/enum.py", line 417, in __new__
> if value in cls._value2member_map:
> TypeError: unhashable type: 'list'
>
> I'll wrap it in a try-except block, but I must admit I was surprised the
> answer wasn't False. After all, if the input is unhashable then obviously
> it's not in the dict; furthermore, if I were to compare the number 5 with a
> set() I would get False, not a TypeMismatch error, and dict keys are
> basically done by equality, the hash is just (?) a speed-up.
"in" is controlled entirely by the container. Both set() and dict()
consider passing them an unhashable object to be a categorical type
error:
>>> [] in set()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> [] in {}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
Equality is different, because people do equality comparisons between
unlike types all the time, so we try *very* hard to ensure "I do not
understand this type" is reported as False rather than "I don't know"
(as indicated by an exception). It's basically the only place where we
do that - pretty much everywhere else, we err on the side of "I do not
understand what this even means" translating to an exception (Python 3
took another big step in that direction by making sure ordered
comparisons between unlike types threw TypeError by default, instead
of returning a dubious answer).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4