Guido van Rossum wrote:
> 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.
I was not aware of this, I assumed it was a implementation issue because
I knew CPython's dicts use a hash table implementation and there are other
ways to implement a mapping data structure i.e. via trees.
Guido could you provide a link to the language definition that dictates these
rules about hashability and (im)mutability?
> A tool like mypy will catch this for you.
Perhaps I should raise this as a mypy issue then?
I'm using mypy version 0.750 as of today and the following code passes with no
errors:
```
"""foo bar."""
from typing import Set, Dict
SOME = {{0}}
print(SOME)
def green_eggs() -> Set[Set[int]]:
"""foo."""
return {{1}}
def and_ham() -> Dict[Set[int], int]:
"""bar."""
return {{1}: 0}
```
Additionally the above code gets a perfect 10/10 out of pylint version 2.4.4
And as a last ditch paranoia fueled attempt formatting with black did nothing
version 19.10b0
> 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)).
Unless they're writing tests, I don't think anyone wants their code to fail.
This pattern is a guaranteed way to do that, and as shown above it's not
being caught on linters/static type checkers as far as i can tell (if it is and
I'm out of date, that's fantastic news! and I'll happily shut up about it :D .)
An experienced user wouldn't typically make this mistake, yes, but regardless
of the user mistakes can still be made and these inadvertently produce failing
code.
> 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?
Luckily there was no grief, I was playing around with the dis module observing
how far the compiler optimized the source before depending on the runtime and
I happened upon the case ``x in {"a", "b"}`` which led me towards ``x in
{{"a"}}``
and ``x in {{0: 1}, {1: 2}}``, and I was surprised that there was valid code
emitted
for such a surefire way to raise an exception.
I first posted here because I thought it was an implementation issue, but as
you've
pointed out it's most certainly a language issue; and one that can be detected
statically.
Now I'd like to suggest that instead of relying on linters and static type
checkers to catch
these bad patterns. Python shouldn't have allowed them in the first place, I
see it as a
contradiction in the language's semantics ultimately deferring the job of
denying the
programmer at the last possible moment.
_______________________________________________
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/4BVFXEP3ZQAN3I3M25246ESZGNWPLCC2/
Code of Conduct: http://python.org/psf/codeofconduct/
