On Sun, Feb 4, 2018 at 7:54 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 5 February 2018 at 08:31, Guido van Rossum <gu...@python.org> wrote:
> > On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal
> > <chris.bar...@noaa.gov> wrote:
> >>
> >> I think the folks that are concerned about this issue are quite right
> >> — most Python users equate immutable and hashable—so the dataclass API
> >> should reflect that.
> >
> > Since they are *not* equivalent (consider a tuple containing a list) I'm
> not
> > at all convinced that any API in the core language should "reflect" this
> > misconception, depending on how you meant that.
> Lists are themselves mutable, and hence inherently unhashable.
> Tuples are themselves immutable, and hence hashable if their contents are.
> I interpret Chris's comment as saying that data classes should behave
> the same way that the builtin container types do:

pretty much, yes,

But a bit more detail -- I'm commenting on the API, not the capability -
that is, since users often equate hashable and immutability, they will
expect that if they say hash=True, then will get an immutable, and if they
say frozen=True, they will get something hashable (as long as the fields
are hashable, just like a tuple.

That is, even though these concepts are independent, the defaults shouldn't
reflect that.

It's the ability to ask the interpreter to guess what you mean
> "frozen=False, hash=True" that creates the likelihood of confusion.

Actually, I think if the user does explicitly specify: "frozen=False,
hash=True", then that's what they should get, and it's a pretty fragile
beast, but apparently there's enough of a use case for folks to want it,
and I don't think it's a confusing API.



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Python-Dev mailing list

Reply via email to