[Python-Dev] Is static typing still optional?

[Gregory P. Smith]

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 "nothing_annotation"
> >
> > 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>