[Python-Dev] Is static typing still optional?

[Chris Barker]

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 at 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 at noaa.gov <mailto:chris.barker at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171215/7fa8053e/attachment.html>