`safe` decorator generates incorrent signature

[stevanmilic]

When function that has Any in it's signature, the safe decorator will generate a function with type hints def (*Any, **Any) -> Any.

Example:

@safe
def send(text: str) -> Any:
    return "test"

reveal_type(send) # Revealed type is 'def (*Any, **Any) -> Any'

If the return type hint is str the safe decorator will produce a correctly typed function.

The problem isn't strictly related to the return type, sometimes if we have an argument that is Dict[str, Any] the function signature would be wrong. This doesn't always occur, it takes that there are other arguments defined too (?) EDIT: it looks like it only happens with async functions.

Is this a known issue? i.e. if Any is present the safe decorator makes the function arguments and return type Any too? This may be the issue with other decorators too, I haven't tested it.

I would be glad to help to solve the issue.

[sobolevn]

Ok, I can very this happens with Any type.

Debug out from mypy plugin:

def (*Any, **Any) -> typing.Coroutine[Any, Any, returns.result.Result[Any, builtins.Exception]]
will copy from def (text: builtins.str) -> Any
revealed: def (text: builtins.str) -> typing.Coroutine[Any, Any, returns.result.Result[Any, builtins.Exception]]

def (*Any, **Any) -> returns.result.Result[Any, builtins.Exception]
will copy from def (text: builtins.str) -> Any
revealed: def (text: builtins.str) -> returns.result.Result[Any, builtins.Exception]

So, mypy plugin works correctly, but then @overload somehow ruins the correct type from each individual check.

The solution will be:

• after we fix Typecheck async functions and decorators #133
• I will remove async @safe case and replace it with @safe_future or similar decorator
• add this regression case into the test spec

Thanks a lot for the reporting. Sadly, but you have to wait for 0.14 release of returns.
It will bring many new awesome features like typed partial, Task monad, and new composition helpers.

Stay tuned!

[stevanmilic]

Yea, looking at the code, I suspected it has something to do with @overload. I like the changes, it makes sense to distinguish the async @safe 👍

Sure, I'll wait, for now I can use the Return explicitly. BTW great work on the library, it brings many interesting ideas from different languages.