[Python-Dev] Is static typing still optional?

Ned Batchelder ned at nedbatchelder.com
Wed Dec 27 00:00:03 EST 2017


On 12/26/17 1:49 PM, Chris Barker wrote:
> On Sat, Dec 23, 2017 at 5:54 PM, Nick Coghlan <ncoghlan at gmail.com 
> <mailto:ncoghlan at gmail.com>> wrote:
>
>
>     I still wonder about the "fields *must* be annotated" constraint
>     though. I can understand a constraint that the style be
>     *consistent* (i.e. all fields as annotations, or all fields as
>     field instances), since that's needed to determine the field
>     order, but I don't see the problem with the "no annotations" style
>     otherwise.
>
>
> IIUC, without annotations, there is no way to set a field with no default.
>
> And supporting both approaches violates "only one way to do it" in, I 
> think, a confusing manner -- particularly if you can't mix and match them.
>
> Also, could does using class attributes without annotations make a 
> mess when subclassing? -- no I haven't thought that out yet.
>
>

I have not been following the design of dataclasses, and maybe I'm 
misunderstanding the state of the work.  My impression is that attrs was 
a thing, and lots of people loved it, so we wanted something like it in 
the stdlib.  Data Classes is that thing, but it is a new thing being 
designed from scratch.  There are still big questions about how it 
should work, but it is already a part of 3.7.

Often when people propose new things, we say, "Put it on PyPI first, and 
let's see how people like it."  Why isn't that the path for Data 
Classes?  Why are they already part of 3.7 when we have no practical 
experience with them?  Wouldn't it be better to let the design mature 
with real experience?  Especially since some of the questions being 
asked are about how it interrelates with another large new feature with 
little practical use yet (typing)?

--Ned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171227/298da01b/attachment.html>


More information about the Python-Dev mailing list