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-le...@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/IUOIEOCI22N3G67HX5BOKBS7Z26KC4FX/
> 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-change-the-world/>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/BMRPKUQNJNISTKGVZTHG7X5ZKRMYX7ZR/
Code of Conduct: http://python.org/psf/codeofconduct/
