This is most definitely a language issue, not just a CPython issue -- the rules around hashability and (im)mutability are due to the language definition, not the whim of an implementer. A tool like mypy will catch this for you. As to the desirability of adding a syntax warning for such situations (when they can be detected statically), I'm not sure -- we generally only do syntax warnings when there is something that even experienced users get wrong, by mistake (e.g. assert (condition, message)). I presume this caused you some grief, or you wouldn't be posting here -- can you describe more of how this bit you, and why the runtime error did not suffice in your case? On Thu, Dec 12, 2019 at 7:49 AM mental na via Python-Dev < python-dev@python.org> wrote:
I'm not sure if this is the right place to bring this up, python-ideas seemed like language issues and python-dev seemed like CPython issues.
There are several unhashable builtin types present in CPython, as of today the ones I've noticed are: lists, dicts, sets, and bytearrays. Two of these are containers that require (at least partially) their members to be hashable: dicts and sets
By this logic you cannot have a set of lists or a dict of sets to ints.
CPython however does not stop or warn you if you attempt to do such a thing until it hits `BUILD_MAP` or `BUILD_SET` during runtime. This is reasonable behavior when it's not possible to infer the member type of the container i.e. ``{f(x) for x in iterable}`` or ``{f(x): y for zip(xs, ys)}``
However, given the situation where literals are nested i.e. ``{[*gen] for gen in gens}`` or ``{{green: eggs}, {and_: ham}}`` this presents an unavoidable exception at runtime. I suggest emitting a SyntaxWarning when encountering these cases of literals that produce unhashable types that are used in literals that produce types where the members must be hashable. I don't think it should be a SyntaxError because it's not a language issue, its an implementation issue. I don't think it should be a linters responsibility because for the most part linters should consider language issues/idioms not side-effects from the running implementation.
I do understand that such cases this issue addresses may be uncommon and once you do get that TypeError raised its a relatively quick and easy fix, but consider this being present in code paths that don't get taken as frequently, large codebases where it becomes difficult to keep track of small one liner literals like this or even for the newer programmers toying with Python through CPython and naively using unhashables in places they shouldn't be.
Either way I'm interested in hearing what the core team thinks of this suggestion, thanks in advance! :D _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IUOIEOCI... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...