[Python-Dev] is typing optional in dataclasses? (original) (raw)

Gregory P. Smith greg at krypto.org
Thu Dec 21 19:19:29 EST 2017

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

More information about the Python-Dev mailing list