[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: New changeset 4cffe2f66b581fa7538f6de884d54a5c7364d8e0 by Eric V. Smith (Miss Islington (bot)) in branch '3.7': bpo-32929: Dataclasses: Change the tri-state hash parameter to the boolean unsafe_hash. (GH-5891) (GH-5902)

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: I'm going to close this. Steven: if you gain support for a parameter name change, please open another issue. -- priority: release blocker -> normal resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Change by miss-islington : -- pull_requests: +5672 ___ Python tracker ___

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: New changeset dbf9cff48a4ad0fd58e1c623ce1f36c3dd3d5f38 by Eric V. Smith in branch 'master': bpo-32929: Dataclasses: Change the tri-state hash parameter to the boolean unsafe_hash. (#5891)

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Guido van Rossum added the comment: @steven.daprano the name was +1'ed by many people in the python-dev discussion as sending the right message. So I'm reluctant to change it. If you can cause a landslide of support for `_hash` there we can change it in b3. --

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: I've been focused on getting the code fix in for the next beta release on 2018-02-26, and leaving the possible parameter name change for later. I don't feel strongly about the parameter name. Right now it's unsafe_hash, per Guido's

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Change by Eric V. Smith : -- keywords: +patch pull_requests: +5663 stage: -> patch review ___ Python tracker ___

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: if unsafe_hash: # If there's already a __hash__, raise TypeError, otherwise add __hash__. if has_explicit_hash: hash_action = 'exception' else: hash_action = 'add' else: #

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Guido van Rossum added the comment: I don't know if I'm unique, but I find such a table with 4 Boolean keys hard to understand. I'd rather see it written up as a series of nested 'if' statements. -- ___ Python tracker

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: Here's the simplest way I can describe this, and it's also the table used inside the code. The column "has-explicit-hash?" is trying to answer the question "is there a __hash__ function defined in this class?". It is set to False if

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Guido van Rossum added the comment: Sorry, I used imprecise language. What you propose is fine. On Feb 24, 2018 09:54, "Eric V. Smith" wrote: > > Eric V. Smith added the comment: > > Note that this class (from the test suite)

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: Note that this class (from the test suite) will now raise an exception: @dataclass(unsafe_hash=True) class C: i: int def __eq__(self, other): return self.i == other.i That's because it

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Guido van Rossum added the comment: It is important to convey the idea that if you are thinking of using this you are probably doing something fishy. An alternative could be `_hash`, which at least indicates it is not for general use, like `sys._getframe()`. --

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Eric V. Smith added the comment: That's a quote from Guido. There weren't any better ideas on the python-dev thread. -- nosy: +gvanrossum ___ Python tracker

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

Steven D'Aprano added the comment: This is a truly awful name, there's nothing unsafe about the hash parameter. We rightly hesitate to label *actual* unsafe functions, like eval and exec, with that name. Are we committed to this name? -- nosy:

[issue32929] Change dataclasses hashing to use unsafe_hash boolean (default to False)

New submission from Eric V. Smith : See https://mail.python.org/pipermail/python-dev/2018-February/152150.html for a discussion. This will remove the @dataclass hash= tri-state parameter, and replace it with an unsafe_hash= boolean-only parameter. >From that thread: """