On Mon, Feb 5, 2018 at 5:17 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> I'm not happy about the concept of pandering to the least capable, most > ignorant programmers by baking a miscomprehension into an important > standard library API. I don't think this is "baking a miscomprehension", but rather adhering to the principle of least surprize. > (Things would be different if we just outright banned mutable+hashable, > but I don't think anyone wants that.) > yeah, though I'm still not sure what the hashable mutable dataclass use case is. Fortunately, I also believe that the number of programmers who would > fail to draw the right conclusion from the existence of separate > switches will actually be pretty small in practice. The fact that there > are two separate switches is a pretty big clue that mutability and > hashability can be controlled separately. > well, yes, but as we all know, more people read code than write it -- so we should be concerned about what a mid-level programmer will conclude when s/he sees: @dataclass(frozen=True) or @dataclass(hash=True) It may not be clear that the other options is available, and what it's default it. > I believe that the proposed API is much simpler to understand than your > revision. We have: > > - frozen and hash both default to False; > - if you explicitly set one, the other uses the default. > > This corresponds to a very common, Pythonic pattern that nearly > everyone is familiar with: > > def spam(frozen=False, hash=False): > ... > > which is easy to understand and easy to explain. Versus your proposal: > > - if you set neither, then frozen and hash both default to False; > - but if you explicitly set one, the other uses True, namely the > opposite of the standard default. > > which corresponds to something harder to describe and much less common: > > def spam(frozen=None, hash=None): > if frozen is hash is None: > frozen = hash = False > elif frozen is None: > frozen = True > elif hash is None: > hash = True > ... > > "frozen and hash default to True, unless neither are set, in which case > they default to False." > I agree that it's easier to document, but we all know no one reads documentation anyway. My argument (which may not be correct) is based on the idea that the hash=True, frozen=False is the rare, specialized use case -- the folks that need that will figure it out. (1) I set frozen=True thinking that makes the class hashable so I can > use it in a set or hash. The first time I actually do so, I get an > explicit and obvious TypeError. Problem solved.[1] > > (2) I set hash=True thinking that makes the class frozen. This scenario > is more problematic, because there's no explicit and obvious error when > I get it wrong. Instead, my program could silently do the wrong thing if > my instances are quietly mutated. > > The first error is self-correcting, and so I believe that the second is > the only one we should worry about. fair enough. > - how much should we worry? (how often will this happen?); > I probably wouldn't be worried at all, except that the word "frozen" is used in the built-in frozenset, with this documentation: """ The frozenset type is immutable and hashable — its contents cannot be altered after it is created; it can therefore be used as a dictionary key or as an element of another set. """ and frozenset pops up pretty high in google if you search "frozen python frozen" (second to the topic of frozen binaries...) > I don't think this is a failure mode that we need to be concerned with. > We can't protect everyone from everything. > I suppose you're right -- I think were we disagree is how confusing my proposal is -- I think the common less error prone use cases should be easy and obvious to do, and the uncommon, more "expert" use-cases should be possible and clearly documented when the code is read. But it's not that big a deal -- I'm done -- thanks for specifically addressing the issues I brought up. -CHB -- Christopher Barker, Ph.D. Oceanographer 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 chris.bar...@noaa.gov
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
