TYP: returning None for __init__

[jreback]

xref #44677 (comment)

we originally had a decision not to type annotate returning None for init

can other folks weigh in here? We have a number of PRs which do exactly this (I merged one or 2 then saw the comments)
e.g. #46283 and a few others.

cc @simonjayhawkins @twoertwein @Dr-Irv @phofl

[twoertwein]

I'm in favor of adding -> None (but wouldn't object for not adding it either)

From PEP 484:

(Note that the return type of init ought to be annotated with -> None. The reason for this is subtle. If init assumed a return annotation of -> None, would that mean that an argument-less, un-annotated init method should still be type-checked? Rather than leaving this ambiguous or introducing an exception to the exception, we simply say that init ought to have a return annotation; the default behavior is thus the same as for other methods.)

As far as I understand it: we should definitely add -> None if we have an __init__ that otherwise wouldn't have any type annotations.

[Dr-Irv]

Looking at numpy, it seems they have done this, and since they are way ahead on typing than we are, we should follow in the footsteps of giants and thus I favor adding -> None to the return types for __init__() throughout the code, probably as one big PR.

[simonjayhawkins]

I think that now we are looking to make the pandas types public, we should probably add the None since the assumed return type was a mypy thing and users type checking their code may use other type checkers, so we should probably now follow the pep.

In the early days, before we had check_untyped_defs=True, adding the None ensured that the function body was checked for __init__ methods with no arguments to type, so there would have been some advantage to adding it selectively, but it was decided that in general it was redundant and therefore not needed.

[simonjayhawkins]

but it was decided that in general it was redundant and therefore not needed.

from #27418 (comment)

pseudo-standard internally not to add

so maybe why not formalized in https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#style-guidelines.

[jreback]

ok i am going to merge the existing PRs.

let's close this issue with an update for the style guide. (and ideally change everything in a small number of PRs)