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:




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.



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