On 10/8/20 5:16 AM, Markus Armbruster wrote:
John Snow <js...@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.
