[Python-Dev] Is static typing still optional? (original) (raw)

Gregory P. Smith greg at krypto.org
Thu Dec 21 18:36:08 EST 2017

On Thu, Dec 21, 2017 at 3:10 PM MRAB <python at mrabarnett.plus.com> wrote:

On 2017-12-21 22:45, Chris Barker wrote: > On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy <tjreedy at udel.edu_ _> <mailto:tjreedy at udel.edu>> wrote: > > I think the understanding problem with this feature arises from two > factors: using annotations to define possibly un-initialized slots > is non-obvious; a new use of annotations for something other than > static typing is a bit of a reversal of the recent pronouncement > 'annotations should only be used for static typing'. > > > you know, that may be where part of my confusion came from -- all the > talk lately has been about "type hints" and "type annotations" -- the > idea of "arbitrary annotations" has been lost. > > Therefore, getting the permanent doc 'right' is important. > > > yup. > > @dataclass > class C: > x > y = 0 > > I think the doc should explicitly say that uninitialized fields > require annotation with something (anything, not necessarily a type) > simply to avoid NameError during class creation. > > > would this be possible? > > @dataclass > class C: > x: > y: = 0 > > That is -- the colon indicates an annotation, but in this case, it's a > "nothing" annotation. > > "..." or "pass", perhaps?

@dataclass class C: x: ... y: ... = 0 or: @dataclass class C: x: pass y: pass = 0

pass does not currently parse in that context. Otherwise I was thinking the same thing. 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)

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

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. (but would annoy people with small 2-3 element data classes... so I'm assuming this idea is already rejected)

-gps

> It's a syntax error now, but would it be possible to change that? Or > would the parsing be ambiguous? particularly in other contexts. > > of course, then we'd need something to store in as a "nothing" > annotation -- empty string? None? (but None might mean something) create > yet anther type for "nothingannotation" > > Hmm, I may have talked myself out of it.... >

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/greg%40krypto.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171221/4d10046c/attachment-0001.html>

More information about the Python-Dev mailing list