Sorry about the email mangling -- I do a lot of my listserve work on the bus on an iPhone, with the built -in mail client -- and it REALLY sucks for doing interspersed email replying -- highly encouraging the dreaded top posting... But anyway, I think both Steve and I were expressing concerns about "Typing Creep". Typing should always be optional in Python, and while this PEP does keep it optional, Steve's point was that the code in the standard library serves not only as a library, but as examples of how to write "robust" python code. The rest of this note is me -- I'm not pretending ot speak for Steve. Reading the PEP, this text makes me uneasy: "A field is defined as any variable identified in__annotations__. That is, a variable that has a type annotation." And if I understand the rest of the PEP, while typing itself is optional, the use of type Annotation is not -- it is exactly what's being used to generate the fields the user wants. And the examples are all using typing -- granted, primarily the built in types, but still: @dataclass class C: a: int # 'a' has no default value b: int = 0 # assign a default value for 'b' This sure LOOKS like typing is required. It also makes me nervous because, as I understand it, the types aren't actually used in the implementation (presumable they would be by mypy and the like?). So I think for folks that aren't using typing and a type checker in their development process, it would be pretty confusing that this means and what it actually does. Particularly folks that are coming from a background of a statically typed language. Then I see: """ Field objects describe each defined field. ... Its documented attributes are: name: The name of the field. type: The type of the field. ... """ So again, typing looks to be pretty baked in to the whole concept. and then: """ One place where dataclass actually inspects the type of a field is to determine if a field is a class variable as defined in PEP 526. """ and """ The other place where dataclass inspects a type annotation is to determine if a field is an init-only variable. It does this by seeing if the type of a field is of type dataclasses.InitVar. """ """ Data Classes will raise a TypeError if it detects a default parameter of type list, dict, or set. """ So: it seems that type hinting, while not required to use Data Classes, is very much baked into the implementation an examples. As I said -- this makes me uneasy -- It's a very big step that essentially promotes the type hinting to a new place in Python -- you will not be able to use a standard library class without at least a little thought about types and typing. I note this: """ This discussion started on python-ideas [9] and was moved to a GitHub repo [10] for further discussion. As part of this discussion, we made the decision to use PEP 526 syntax to drive the discovery of fields. """ I confess I only vaguely followed that discussion -- in fact, mostly I thought that the concept of Data Classes was a good one, and was glad to see SOMETHING get implemented, and didn't think I had much to contribute to the details of how it was done. So these issues may have already been raised and considered, so carry on. But: NOTE: from PEP 526: "Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention. " The Data Classes implementation is not making it mandatory by any means, but it is making it a more "standard" part of the language that can not simply be ignored anymore. And it seems some features of dataclasses can only be accessed via actual typing, in addition to the requirement of type annotations. If nothing else, the documentation should make it very clear that the typing aspects of Data Classes is indeed optional, and preferably give some untyped examples, something like: @dataclass class C: a: None # 'a' has no default value b: None = 0 # assign a default value for 'b' If, in fact, that would be the way to do it. -Chris On Fri, Dec 15, 2017 at 3:22 AM, Eric V. Smith <eric@trueblade.com> wrote:
On 12/15/2017 5:56 AM, Steve Holden wrote:
On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal < chris.barker@noaa.gov <mailto:chris.barker@noaa.gov>> wrote:
...
However, typing is not currently imported by dataclasses.py.
And there you have an actual reason besides my uneasiness :-)
- CHB
hmm...
[Agreed with Antoine on the MUA and quoting being confusing.]
The only reason typing isn't imported is performance. I hope that once PEP 560 is complete this will no longer be an issue, and dataclasses will always import typing. But of course typing will still not be needed for most uses of @dataclass or make_dataclass(). This is explained in the PEP.
Eric.
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov