[Python-Dev] is typing optional in dataclasses?

[Gregory P. Smith]

(subject for this sub-thread updated)

On Thu, Dec 21, 2017 at 4:08 PM Chris Barker <chris.barker at noaa.gov> wrote:

> On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith <greg at krypto.org> wrote:
>
>
>>  But we already have ... which does - so I'd suggest that for people who
>> are averse to importing anything from typing and using the also quite
>> readable Any.  (ie: document this as the expected practice with both having
>> the same meaning)
>>
>
> I don't think they do, actually - I haven't been following the typing
> discussions, but someone in this thread said that ... means "use the type
> of teh default" or something like that.
>

indeed, they may not.  though if that is the definition is it reasonable to
say that type analyzers recognize the potential recursive meaning when the
_default_ is ... and treat that as Any?

another option that crossed my mind was "a: 10" without using =.  but that
really abuses __attributes__ by sticking the default value in there which
the @dataclass decorator would presumably immediately need to undo and fix
up before returning the class.  but I don't find assigning a value without
an = sign to be pythonic so please lets not do that! :)


>
>> While I consider the annotation to be a good feature of data classes, it
>> seems worth documenting that people not running a type analyzer should
>> avoid declaring a type.
>>
>
> +1 !
>
>
>> A worse thing than no-type being specified is a wrong type being
>> specified. That appearing in a library will break people who need their
>> code to pass the analyzer and pytype, mypy, et. al. could be forced to
>> implement a typeshed.pypi of sorts containing blacklists of known bad
>> annotations in public libraries and/or actually correct type specification
>> overrides for them.
>>
>
> and the wrong type could be very common -- folks using "int", when float
> would do just fine, or "list" when any iterable would do, the list goes on
> and on. Typing is actually pretty complex in Python -- it's hard to get
> right, and if you aren't actually running a type checker, you'd never know.
>

Yeah, that is true.  int vs float vs Number, etc.  It suggests means we
shouldn't worry about this problem at all for the pep 557 dataclasses
implementation.  Type analyzers by that definition are going to need to
deal with incorrect annotations in data classes as a result no matter what
so they'll deal with that regardless of how we say dataclasses should work.

-gps


>
> One challenge here is that annotations, per se, aren't only for typing. Bu
> tit would be nice if a type checker could see whatever "non-type" is
> recommended for dataclasses as "type not specified". Does an ellipses spell
> that? or None? or anything that doesn't have to be imported from typing :-)
>
> As for problems with order, if we were to accept
>>
>> @dataclass
>> class Spam:
>>     beans = True
>>     ham: bool
>>
>> style instead, would it be objectionable to require keyword arguments
>> only for dataclass __init__ methods?  That'd get rid of the need to care
>> about order.
>>
>
> wouldn't  that make the "ham: bool" legal -- i.e. no default?
>
> -CHB
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE
> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171222/090261a3/attachment.html>