Allow __init__ with signature but no return type

[JukkaL]

Code:

class Visitor:
    def __init__(self, a: int):
        pass

Error:

x.py: In member "__init__" of class "Visitor":
x.py, line 2: Cannot define return type for "__init__"

The return type is Any (implicitly), and Any should be a valid return type for __init__.

This was reported by Guido.

[gvanrossum]

Hm, I think the return type for init should be None. A "return " inside an init is almost certainly caused by a misunderstanding. (Maybe you're thinking of new, which does return the object it created?)

[JukkaL]

Ah, the issue is that the error message is wrong. The message should say that the return type must be None? The message may be a relict from times before Python-compatible syntax.

[gvanrossum]

But why do I have to specify the return type at all? Can't it default to
None here?

On Wednesday, March 18, 2015, Jukka Lehtosalo notifications@github.com
wrote:

Closed #604 #604 via 182a70b
182a70b
.

—
Reply to this email directly or view it on GitHub
#604 (comment).

--Guido van Rossum (on iPad)

[JukkaL]

Because of consistency. Consider __init__ that takes no arguments, other than self:

def __init__(self):
    ...

Would this be dynamically typed or statically typed? The current approach is to treat any function that has no annotation (no argument or return types) as dynamically typed, and statically typed (i.e. type checked) otherwise. The None return type marks the function as type checked.

Same goes for functions in general:

def f():   # Dynamically typed
    ...
def f() -> None:   # Statically typed
    ...
def g(x: int):  # Statically typed, Any return type
    ...

[gvanrossum]

Hm. I think it'd suck if we'd have to develop the habit of adding explicit
"-> None" to all init methods just to make mypy happy.

On Thu, Mar 19, 2015 at 8:11 PM, Jukka Lehtosalo notifications@github.com
wrote:

Because of consistency. Consider init that takes no arguments, other
than self:

def init(self):
...

Would this be dynamically typed or statically typed? The current approach
is to treat any function that has no annotation (no argument or return
types) as dynamically typed, and statically typed (i.e. type checked)
otherwise. The None return type marks the function as type checked.

Same goes for functions in general:

def f(): # Dynamically typed
...
def f() -> None: # Statically typed
...
def g(x: int): # Statically typed, Any return type
...

—
Reply to this email directly or view it on GitHub
#604 (comment).

--Guido van Rossum (python.org/~guido)

[JukkaL]

Okay, let's reopen this. Here's a proposed new spec. Let me know if it matches your thinking.

-> None would only be needed for type checked __init__ methods that take no arguments:

def __init__(self) -> None:
    ...

(In my Python corpus, these account for about 15% of all __init__ methods. __init__ methods seem to cover about 10% of all methods.)

An __init__ method with any argument types would be type checked, and the return type would always be None implicitly, but you can also give an explicit None return type if you want.

What about other functions and methods that have arguments with types but don't have an explicit return type? Should they always default to an Any return type? I see a few potential alternatives to this:

1. Default to a None return type, similar to __init__.
2. Default to a None return type if there is no return statement with an explicit value in the body. Give an error otherwise.
3. Default to a None return type if there is no return statement with an explicit value in the body. Default to an Any return type otherwise.
4. Try to infer the return type automatically. I don't like this much because it adds complexity, reduces consistency and "explicit is better than implicit" in this case, in my opinion.

[gvanrossum]

It's a tricky issue, since we need to balance the desire to catch errors in the body of the function (what if a return type was intended but accidentally omitted?) with the need to derive the most useful return type for the benefit of checking call sites, as well as making the system be pleasant to use. I think for methods in general the status quo is fine, but (2) and (3) have some slight advantage, and some even slighter downside.

However I still think __init__ is a special case -- its return value is determined by how Python uses it, not by what the user might want it to return. I think the absence of -> None should never result in an error message here (and in fact -> something_else should be considered an error, even -> Any). The heuristic over whether a function is considered type-checked or not is somewhat unfortunate but I can live with the requirement to add a dummy -> None to type-check an __init__ method that has no arguments besides self.

[JukkaL]

I'm leaning towards using the same convention everywhere (2) -- missing return type (if the signature has argument types) is the same as -> None. One reason is that in many examples of PEP 484 / mypy code I've seen, people tend to omit return types, even though their intention was probably not to have an Any return type -- they just did the easiest/shortest thing. Programmers are lazy, and we probably shouldn't make the rare case (Any return) easier to write than the common case (None return) when we have a choice.

Still, a convention of using an explicit -> None even when it's not needed (except for __init__, where it isn't useful, as you argued) may be a reasonable thing. However, perhaps it shouldn't be enforced.

Here's some more stats (these are actually pretty interesting): In my corpus about half of all methods have signature (self) -- but only a small fraction of these are __init__ methods. Approx. 2/3 of (self) methods seem to have None as the expected return type. Top-level functions that take no arguments but have a None return type are much less frequent.

[gvanrossum]

I'm assuming those argument-less None-returning methods are some kind of pattern to set/clear specific flags? E.g. set_debug(). Would be interesting to look at these a bit more, since the stats look a bit suspicious. OTOH it's understandable that there aren't many top-level functions like that -- changing global state is frowned upon more than changing instance state.