qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 19/36] qapi/events.py: add type hint annotations


From: John Snow
Subject: Re: [PATCH v5 19/36] qapi/events.py: add type hint annotations
Date: Thu, 8 Oct 2020 12:19:39 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 10/8/20 5:16 AM, Markus Armbruster wrote:
John Snow <jsnow@redhat.com> writes:

On 10/7/20 7:49 AM, Markus Armbruster wrote:
Looks like commit message of PATCH 24 has an answer.
Copy to all the commits that omit -> None similarly?

Probably not needed.

It's covered by the class basics section in the mypy manual;
https://mypy.readthedocs.io/en/stable/class_basics.html#annotating-init-methods

and if you should happen to omit annotations for __init__ entirely as
a novice, you will be treated to messages such as these:

qapi/source.py:18: error: Function is missing a return type annotation
qapi/source.py:18: note: Use "-> None" if function does not return a value
Found 1 error in 1 file (checked 14 source files)

Pretty good error!

There's no error if you DO explicitly add a -> None from __init__, but
at worst it's just extraneous (but correct) information.

Let me apply the zero-one-infinity rule:

* Zero: explain it in none of the commit messages, i.e. dumb down PATCH
   24.

* One: explain it in one.  Do it in the first one, please (here, I
   think).

* Infinity: explain it in every one.

Up to you!


I'm just bad at predicting which things people will want explained. I know people don't read the cover letters already, so I'd rather go for less instead of more.

I think you and Cleber each noticed a different angle of this: Cleber noticed the first time I *did* annotate __init__'s return and you noticed the first time I *didn't*.

I'll just add it here too, but I have doubts it will be useful reference once it's merged. I guess it doesn't hurt to add it either, I just find it difficult to predict what reviewers will want.

I could add a note to the style guide that I prefer omitting the
return from __init__. I like omitting as much as I possibly can.

(You'll notice I don't always type every local, either -- when local
inference is accurate, I leave it alone.)

Type inference can save us from repeating the obvious over and over, and
that's lovely.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]