One other note (see my last message). The PEP should include a summary of the discussion of the decision to use the type annotation syntax vs other options.
I just looked through all the gitHub issues and found nothing, and started to look at the python-ideas list archive and got overwhelmed. So having that justification in the PEP would be good. -CHB On Fri, Dec 15, 2017 at 12:07 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > 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 <e...@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.bar...@noaa.gov <mailto:chris.bar...@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.bar...@noaa.gov > -- 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.bar...@noaa.gov
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com