[Python-Dev] Is static typing still optional?

[Guido van Rossum]

I think this is a good candidate for fine-tuning during the beta period.

Though honestly Python's own rules for when a class is hashable or not are
the root cause for the complexity here -- since we decided to implicitly
set __hash__ = None when you define __eq__, it's hardly surprising that
dataclasses are having a hard time making natural rules.

On Sun, Jan 28, 2018 at 5:07 PM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

>
> >>> 2) Change the default value for "hash" from "None" to "False".  This
> might take a little effort because there is currently an oddity where
> setting hash=False causes it to be hashable.  I'm pretty sure this wasn't
> intended ;-)
> >> I haven't looked at this yet.
> >
> > I think the hashing logic explained in https://bugs.python.org/
> issue32513#msg310830 is correct. It uses hash=None as the default, so
> that frozen=True objects are hashable, which they would not be if
> hash=False were the default.
>
> Wouldn't it be simpler to make the options orthogonal?  Frozen need not
> imply hashable.  I would think if a user wants frozen and hashable, they
> could just write frozen=True and hashable=True.  That would more explicit
> and clear than just having frozen=True imply that hashability gets
> turned-on implicitly whether you want it or not.
>
> > If there's some case there that you disagree with, I'd be interested in
> hearing about it.
> >
> > That logic is what is currently scheduled to go in to 3.7 beta 1. I have
> not updated the PEP yet, mostly because it's so difficult to explain.
>
> That might be a strong hint that this part of the API needs to be
> simplified :-)
>
> "If the implementation is hard to explain, it's a bad idea." -- Zen
>
> If for some reason, dataclasses really do need tri-state logic, it may be
> better off with enum values (NOT_HASHABLE, VALUE_HASHABLE,
> IDENTITY_HASHABLE, HASHABLE_IF_FROZEN or some such) rather than with None,
> True, and False which don't communicate enough information to understand
> what the decorator is doing.
>
> > What's the case where setting hash=False causes it to be hashable? I
> don't think that was ever the case, and I hope it's not the case now.
>
> Python 3.7.0a4+ (heads/master:631fd38dbf, Jan 28 2018, 16:20:11)
> [GCC 7.2.0] on darwin
> Type "copyright", "credits" or "license()" for more information.
>
> >>> from dataclasses import dataclass
> >>> @dataclass(hash=False)
> class A:
>     x: int
>
> >>> hash(A(1))
> 285969507
>
>
> I'm hoping that this part of the API gets thought through before it gets
> set in stone.  Since dataclasses code never got a chance to live in the
> wild (on PyPI or some such), it behooves us to think through all the
> usability issues.  To me at least, the tri-state hashability was entirely
> unexpected and hard to debug -- I had to do a close reading of the source
> to figure-out what was happening.
>
>
> Raymond
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180128/d0bd5f7b/attachment.html>