Re: [Python-Dev] Dataclasses and correct hashability

On 7 February 2018 at 12:48, Guido van Rossum wrote: > That seems a rare case (though I hadn't thought of it). I had thought of the > use case where you want a frozen type without a hash; that you can > presumably implement using > > def __hash__(self): raise TypeError("not hashable") Now that at

Re: [Python-Dev] Dataclasses and correct hashability

I'm not a fan, sorry. On Tue, Feb 6, 2018 at 7:33 PM, Ethan Furman wrote: > On 02/06/2018 06:48 PM, Guido van Rossum wrote: > > That seems a rare case (though I hadn't thought of it). I had thought of >> the use case where you want a frozen type >> without a hash; that you can presumably impleme

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 06:48 PM, Guido van Rossum wrote: That seems a rare case (though I hadn't thought of it). I had thought of the use case where you want a frozen type without a hash; that you can presumably implement using def __hash__(self): raise TypeError("not hashable") We can do a similar th

Re: [Python-Dev] Dataclasses and correct hashability

That seems a rare case (though I hadn't thought of it). I had thought of the use case where you want a frozen type without a hash; that you can presumably implement using def __hash__(self): raise TypeError("not hashable") We can do a similar thing to preserve the superclass __hash__ if it's rare

Re: [Python-Dev] Dataclasses and correct hashability

Sorry for the late reply. Still recovering from a computer failure. My only concern with this approach is: what if you don’t want any __hash__ added? Say you want to use your base class’s hashing. I guess you could always “del cls.__hash__” after the class is created, but it’s not elegant. Th

Re: [Python-Dev] Dataclasses and correct hashability

On Tue, Feb 6, 2018 at 12:44 PM, Ethan Furman wrote: > Although, couldn't we add a field-level frozen attribute (using property > for the implementation), and check that all equality fields are properties > as well as hashable? > That would be a totally unrelated feature request. Let's wait whet

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 12:24 PM, Guido van Rossum wrote: On Tue, Feb 6, 2018 at 11:40 AM, Ethan Furman wrote: It sounds like `unsafe_hash=True` indicates a truly unsafe hash (that is, >> mutable data is involved in the hash calculation), but there still seems >> to be one possibility for an "unsafe_ha

Re: [Python-Dev] Dataclasses and correct hashability

On Tue, Feb 6, 2018 at 11:40 AM, Ethan Furman wrote: > It sounds like `unsafe_hash=True` indicates a truly unsafe hash (that is, > mutable data is involved in the hash calculation), but there still seems to > be one possibility for an "unsafe_hash" to actually be safe -- that is, if > only immuta

Re: [Python-Dev] Dataclasses and correct hashability

That's much less self-descriptive and harder to search Google or StackOverflow for. It's also easier to overlook. We really want to send the signal that this is unsafe and requires serious consideration before it is turned on. On Tue, Feb 6, 2018 at 11:57 AM, David Mertz wrote: > Honestly, the n

Re: [Python-Dev] Dataclasses and correct hashability

On 2/6/18 2:40 PM, Ethan Furman wrote: On a different note, should the PEP be updated with the current signature? It still talks about hash=None being the default. Once we've reached an agreement, I'll update the PEP. I don't think we're there quite yet. Eric ___

Re: [Python-Dev] Dataclasses and correct hashability

Honestly, the name I would most want for the keyword argument is '_hash'. That carries the semantics I desire. On Feb 6, 2018 10:13 AM, "Ethan Furman" wrote: > On 02/06/2018 09:38 AM, Guido van Rossum wrote: > > Where do you get the impression that one would have to explicitly request >> __hash_

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 11:18 AM, Guido van Rossum wrote: We may be in violent agreement. I propose *not* to add a way to *disable* hashing when the rest of the flags to @dataclass() would indicate that it's safe to add a __hash__ method. Okay. I propose that with @dataclass(unsafe_hash=False) (the

Re: [Python-Dev] Dataclasses and correct hashability

We may be in violent agreement. I propose *not* to add a way to *disable* hashing when the rest of the flags to @dataclass() would indicate that it's safe to add a __hash__ method. I propose that with @dataclass(unsafe_hash=False) (the default), a __hash__ method is added when the following condi

Re: [Python-Dev] Dataclasses and correct hashability

On 02/06/2018 09:38 AM, Guido van Rossum wrote: Where do you get the impression that one would have to explicitly request __hash__ if frozen=True is set? To the contrary, my proposal is for @dataclass to automatically add a __hash__ method when frozen=True is set. This is what the code current

Re: [Python-Dev] Dataclasses and correct hashability

Where do you get the impression that one would have to explicitly request __hash__ if frozen=True is set? To the contrary, my proposal is for @dataclass to automatically add a __hash__ method when frozen=True is set. This is what the code currently released as 3.7.0b1 does if hash=None (the default

Re: [Python-Dev] Dataclasses and correct hashability

On Mon, Feb 05, 2018 at 10:50:21AM -0800, David Mertz wrote: > Absolutely I agree. 'unsafe_hash' as a name is clear warning to users. (I don't mean to pick on David specifically, I had to reply to some message in this thread and I just picked his.) I'm rather gobsmacked at the attitudes of many

Re: [Python-Dev] Dataclasses and correct hashability

To add a counter-example that I'm painfully familiar with: the old Thrift for Python makes its (mutable) structures hashable. This is "useful" because you can memoize functions that take Thrift structures as arguments. You can key dictionaries with them. And so on. Unfortunately, more often the

Re: [Python-Dev] Dataclasses and correct hashability

Just wanted to add my 5 cents here. I am a bit surprised how people are scared by adding `__hash__` to mutable classes. >From my experience it is quite normal, I was always thinking about `hash()` as hashing a _value_, and never as hashing _identity_, if I would need the latter, there is a differen

Re: [Python-Dev] Dataclasses and correct hashability

On 6 February 2018 at 03:47, Guido van Rossum wrote: > If there's going to be an API for it, it should be in the class, not > something that mutates the class afterwards. Something I realised after posting the __class__ setting idea is that you can actually use a comparable trick to inject an uns

Re: [Python-Dev] Dataclasses and correct hashability

I don't think it matters so much whether you are stacking two decorators or a single decorator, but would an @add_unsafe_hash decorator be useful for anything *except* data classes? If not, then there's no point in having a *second* decorator that can *only* modify the first one - particularly

Re: [Python-Dev] Dataclasses and correct hashability

Yes, that's what I meant -- "afterwards" meaning after the @dataclass decorator is applied. On Mon, Feb 5, 2018 at 11:09 AM, Kirill Balunov wrote: > > 2018-02-05 20:47 GMT+03:00 Guido van Rossum : > >> If there's going to be an API for it, it should be in the class, not >> something that mutates

Re: [Python-Dev] Dataclasses and correct hashability

2018-02-05 20:47 GMT+03:00 Guido van Rossum : > If there's going to be an API for it, it should be in the class, not > something that mutates the class afterwards. > I apologize and don't want to make unnecessary noise. But the already selected design with decorator @dataclass implies that it wi

Re: [Python-Dev] Dataclasses and correct hashability

Absolutely I agree. 'unsafe_hash' as a name is clear warning to users. On Feb 4, 2018 10:43 PM, "Chris Barker" wrote: On Sun, Feb 4, 2018 at 11:57 PM, Gregory P. Smith wrote: > +1 using unsafe_hash as a name addresses my concern. > mine too -- anyone surprised by using this deserves what the

Re: [Python-Dev] Dataclasses and correct hashability

If there's going to be an API for it, it should be in the class, not something that mutates the class afterwards. On Mon, Feb 5, 2018 at 1:59 AM, Kirill Balunov wrote: > On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum > wrote: >> >> Looks like

Re: [Python-Dev] Dataclasses and correct hashability

I'm sorry, but a solution that requires __class__ assignment is way too fragile for my taste. On Mon, Feb 5, 2018 at 6:28 AM, Nick Coghlan wrote: > On 5 February 2018 at 15:49, Guido van Rossum wrote: > > My point is that once you have one of those patterns in place, changing > your > > code to

Re: [Python-Dev] Dataclasses and correct hashability

On 5 February 2018 at 15:49, Guido van Rossum wrote: > My point is that once you have one of those patterns in place, changing your > code to avoid them may be difficult. And yet your code may treat the objects > as essentially immutable after the initialization phase (e.g. a parse tree). > So if

Re: [Python-Dev] Dataclasses and correct hashability

On 2/5/2018 2:28 AM, Glenn Linderman wrote: This is an interesting use case. I haven't got the internals knowledge to know just how just different mutable and immutable classes and objects are under the hood. I believe there is no internal difference. An object is immutable if there is not

Re: [Python-Dev] Dataclasses and correct hashability

On 2/5/2018 12:11 AM, Nathaniel Smith wrote: On Sun, Feb 4, 2018 at 11:28 PM, Glenn Linderman wrote: This is an interesting use case. I haven't got the internals knowledge to know just how just different mutable and immutable classes and objects are under the hood. But this use case makes me wo

Re: [Python-Dev] Dataclasses and correct hashability

On Sun, Feb 4, 2018 at 11:28 PM, Glenn Linderman wrote: > This is an interesting use case. I haven't got the internals knowledge to > know just how just different mutable and immutable classes and objects are > under the hood. But this use case makes me wonder if, even at the cost of > some perfor

Re: [Python-Dev] Dataclasses and correct hashability

On 2/4/2018 9:49 PM, Guido van Rossum wrote: A frozen class requires a lot of discipline, since you have to compute the values of all fields before calling the constructor. A mutable class allows other initialization patterns, e.g. manually setting some fields after the instance has been constr

Re: [Python-Dev] Dataclasses and correct hashability

On Sun, Feb 4, 2018 at 11:57 PM, Gregory P. Smith wrote: > +1 using unsafe_hash as a name addresses my concern. > mine too -- anyone surprised by using this deserves what they get :-) -CHB On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote: > >> Looks like this is turning into a major flamew

Re: [Python-Dev] Dataclasses and correct hashability

+1 using unsafe_hash as a name addresses my concern. It's a good signal that there are caveats worth considering. -gps On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote: > Looks like this is turning into a major flamewar regardless of what I say. > :-( > > I really don't want to lose the abil

Re: [Python-Dev] Dataclasses and correct hashability

Looks like this is turning into a major flamewar regardless of what I say. :-( I really don't want to lose the ability to add a hash function to a mutable dataclass by flipping a flag in the decorator. I'll explain below. But I am fine if this flag has a name that clearly signals it's an unsafe th

Re: [Python-Dev] Dataclasses and correct hashability

>> IMO, the danger of >> "@dataclass(hash=True)" far overweighs whatever convenience it might >> provide. Is there any reason specifying has=True could set frozen=True unless the user specifically sets frozen=False? Or is that already the case? I think the folks that are concerned about this iss

Re: [Python-Dev] Dataclasses and correct hashability

As a Bear of Relatively Little Brain, I've grown up understanding, and teaching, that mutable things aren't to be used as dict keys. I'm aware that immutability isn't strictly the required condition, but it for most people, that's the primary reason for using frozen sets and tuples, for example, an

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 10:44 PM, Guido van Rossum wrote: It appears Eric and I are the only ones in favor of keeping the current behavior. But I still am not convinced by all the worries about "attractive nuisances" and all the other bad names this feature has been called. We don't know that any of the

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 10:25 PM Nick Coghlan wrote: > > > On 3 Feb. 2018 1:09 am, "Eric V. Smith" wrote: > > > The problem with dropping hash=True is: how would you write __hash__ > yourself? It seems like a bug magnet if you're adding fields to the class > and forget to update __hash__, especia

Re: [Python-Dev] Dataclasses and correct hashability

It appears Eric and I are the only ones in favor of keeping the current behavior. But I still am not convinced by all the worries about "attractive nuisances" and all the other bad names this feature has been called. We don't know that any of the doomsday scenarios will happen. In my experience, us

Re: [Python-Dev] Dataclasses and correct hashability

On 3 Feb. 2018 1:09 am, "Eric V. Smith" wrote: The problem with dropping hash=True is: how would you write __hash__ yourself? It seems like a bug magnet if you're adding fields to the class and forget to update __hash__, especially in the presence of per-field hash=False and eq=False settings. A

Re: [Python-Dev] Dataclasses and correct hashability

I agree with Ethan, Elvis, and a few others. I think 'hash=True, frozen=False' should be disabled in 3.7. It's an attractive nuisance. Maybe not so attractive because its obscurity, but still with no clear reason to exist. If many users of of dataclass find themselves defining '__hash__' with mut

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 08:09 AM, Eric V. Smith wrote: On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: My point is exactly that there is _no_ valid use case, so (hash=True, frozen=False) should not be a thing! Why are you so insistent on adding a dangerous option which you admit is nearly useless? B

Re: [Python-Dev] Dataclasses and correct hashability

On 02/02/2018 08:14 AM, Yury Selivanov wrote: Eric, in my opinion we shouldn't copy attrs. [...] We are designing a new API that is going to be hugely popular. Why can't we ship it with dangerous options prohibited in 3.7 (it's easy to do that!) and then enable them in 3.8 when there's an a

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 7:38 AM, Elvis Pranskevichus wrote: > On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: > > However, I don't feel very strongly about this. As I've said, I expect > > the use cases for hash=True to be very, very rare. > > Why do you think that the requirement

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: I was specifically talking about the case of a non-frozen, hashable class. If you want to make a class frozen and hashable, then: @dataclass(frozen=True) will do just that. The ca

Re: [Python-Dev] Dataclasses and correct hashability

> Because it's not the default, it will be documented as being an > advanced use case, and it's useful in rare instances. > > And as I've said a number of times, both here and in other > discussions, I'm not arguing strenuously for this. I just think that, > given that it's not the default and it'

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 10:51 AM, Paul Moore wrote: [..] > To put it another way, using your words above, "The moment you want to > use a dataclass a a dict key, or put it in a set, you need it to be > *immutable*" (not hashable, unless you really know what you're doing). Can someone clarify what

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: > I was specifically talking about the case of a non-frozen, hashable > class. If you want to make a class frozen and hashable, then: > > @dataclass(frozen=True) > > will do just that. > > The case you brought up initially is the n

Re: [Python-Dev] Dataclasses and correct hashability

On 2 February 2018 at 15:38, Elvis Pranskevichus wrote: > On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: >> However, I don't feel very strongly about this. As I've said, I expect >> the use cases for hash=True to be very, very rare. > > Why do you think that the requirement to ma

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:38 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: However, I don't feel very strongly about this. As I've said, I expect the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a dataclass

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: > However, I don't feel very strongly about this. As I've said, I expect > the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a dataclass hashable is a "very, very rare" requirement? T

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 12:33 AM, Nick Coghlan wrote: For 3.7, I think we should seriously considered just straight up disallowing the "hash=True, frozen=False" combination, and instead require folks to provide their own hash function in that case. "Accidentally hashable" (whether by identity or field hash)

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 12:33:04 AM EST Nick Coghlan wrote: > For 3.7, I think we should seriously considered just straight up > disallowing the "hash=True, frozen=False" combination, and instead > require folks to provide their own hash function in that case. > "Accidentally hashable" (whethe

Re: [Python-Dev] Dataclasses and correct hashability

On 2 February 2018 at 11:49, Elvis Pranskevichus wrote: > In my experience this type of breakage is so subtle that people will > happily write code lots of code like this without noticing. My main > objection here is that the dataclass does not go far enough to prevent > obviously wrong behaviour

Re: [Python-Dev] Dataclasses and correct hashability

On Thursday, February 1, 2018 8:37:41 PM EST Eric V. Smith wrote: > > hash=None and compare=True leads to the same result, which, I > > think is even worse. > > Have you actually tried that? I meant this: @dataclasses.dataclass(hash=True) class A: foo: int = dataclasses.field(compare=True)

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 8:29 PM, Elvis Pranskevichus wrote: On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: I should add: This is why you shouldn't override the default (hash=None) unless you know what the consequences are. Can I ask why you want to specify hash=True? hash=None and compa

Re: [Python-Dev] Dataclasses and correct hashability

On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: > I should add: This is why you shouldn't override the default > (hash=None) unless you know what the consequences are. Can I ask > why you want to specify hash=True? hash=None and compare=True leads to the same result, which, I thi

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 8:17 PM, Eric V. Smith wrote: On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote: There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections requires that a

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote: There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections requires that a key’s hash value is immutable (if the obje