I think this cannot just be considered a bug fix, and it seems somewhat fundamental (catching arbitrary exceptions is controversial), so I recommend finding a core dev to sponsor a PEP. (Or finding one who thinks it is obviously a bug and will approve a PR.) On Tue, Jul 21, 2020 at 04:43 Dominik Vilsmeier <dominik.vilsmeier@gmx.de> wrote:
On 07.07.20 19:41, Stephen J. Turnbull wrote:
Dominik Vilsmeier writes:
So if you're dealing with items views and want to compare them to a set representing dict items, then you need an extra `try/except` in order to handle non-hashable values in the items view.
Sounds like you have a change to propose here, then. Put the try/except in the __eq__ for the items view class when comparing against a set. I would expect it to be accepted, as comparing items views is pretty expensive so the slight additional overhead would likely be acceptable, and if you get the exception, you know the equality comparison against a set is false since a set cannot contain that element, so this possibility can't affect worst-case performance by much, if at all.
So it seems there is a consensus on the fact that this is undesirable behavior and it can be fixed relatively easy.
What's the next step then? Should this be discussed further on the mailing list? Should I open an issue at bpo? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/G7N7WV... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)