[Python-Dev] Is static typing still optional?

Fri Dec 15 15:19:56 EST 2017

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.barker at 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 <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
>

-- 

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/dc36984a/attachment.html>