Problem with alias for Optional[str]

[RoccoMatano]

Since i just started to use mypy i am not sure whether this might be more a problem on my side, but nevertheless here it comes:

I am using python 3.6 and mypy 0.511 on windows and stumbled across a case of using a type alias where mypy reports a problem, while i am sure it shouldn't. I think the following console says it (almost) all:

c:\prj\SRC\Python\test_mypy>type test_mypy.py

import sys
import typing
print(sys.version)

def test_ok_1() -> typing.Optional[str]:
    return None

def test_ok_2() -> typing.Optional[str]:
    return "string"

def test_ok_3(what: bool) -> typing.Optional[str]:
    if what:
        return "string"
    else:
        return None

OptionalString = typing.Optional[str]

def test_fail_1() -> OptionalString:
    return None

def test_fail_2() -> OptionalString:
    return "string"

def test_fail_3(what: bool) -> OptionalString:
    if what:
        return "string"
    else:
        return None

c:\prj\SRC\Python\test_mypy>py test_mypy.py
3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit (AMD64)]

c:\prj\SRC\Python\test_mypy>py -m mypy -V
mypy 0.511

c:\prj\SRC\Python\test_mypy>py -m mypy test_mypy.py
test_mypy.py:21: error: Invalid type "test_mypy.OptionalString"
test_mypy.py:24: error: Invalid type "test_mypy.OptionalString"
test_mypy.py:27: error: Invalid type "test_mypy.OptionalString"

c:\prj\SRC\Python\test_mypy>

I would have expected that there should be no difference between using 'typing.Optional[str]' and its alias 'OptionalString'

[gvanrossum]

Hm, confirmed in a smaller program:

from typing import Optional
OptionalString = Optional[str]
def f() -> OptionalString: ...

This gives

__tmp__.py:3: error: Invalid type "__tmp__.OptionalString"

However when I add the --strict-optional flag to mypy it works fine. The code also works fine when the function definition uses Optional[str] (i.e. no alias) so this does feel like a bug with strict-optional and aliasing. @ddfisher any thoughts on this?

[gvanrossum]

Looks like this will be fixed by @ilevkivskyi's PR #3524.

[ilevkivskyi]

Looks like this will be fixed by @ilevkivskyi's PR #3524.

Yes, it should be fixed. Essentially, this is practically a duplicate of #3191