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
> > 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
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