PyRight shows errors for operator return values

[Andrej730]

Not sure when this one occurred and I guess it's not a bug but now every operator have this issue with return value.

Options I see:

• return some kind of constant like FINISHED that is defined as set["FINISHED"]
• define OperatorReturnType = set[Literal['RUNNING_MODAL', 'CANCELLED', 'FINISHED', 'PASS_THROUGH', 'INTERFACE']] and declare it explicitly as -> OperatorReturnType to .execute().

Any ideas for workarounds that wouldn't need creating new variables just to avoid typing issues?

import bpy

class Test(bpy.types.Operator):
    def execute(self, context):
        # Method "execute" overrides class "Operator" in an incompatible manner
        # Return type mismatch: base method returns type "set[Literal['RUNNING_MODAL', 'CANCELLED', 'FINISHED', 'PASS_THROUGH', 'INTERFACE']]", override returns type "set[str]"
        #     "set[str]" is incompatible with "set[Literal['RUNNING_MODAL', 'CANCELLED', 'FINISHED', 'PASS_THROUGH', 'INTERFACE']]"
        #     Type parameter "_T@set" is invariant, but "str" is not the same as "Literal['RUNNING_MODAL', 'CANCELLED', 'FINISHED', 'PASS_THROUGH', 'INTERFACE']"
        return {"FINISHED"}

[JonathanPlasse]

• I made a follow-up PR to solve this problem Update: Create type aliases for rna enums #300

[Andrej730]

This would mean rewriting all operators .execute and .invoke methods signatures and explicitly specifying their return type :(

[JonathanPlasse]

Yes, this is a compromise.
Either we have auto-completion and type checking of the return literals but being more verbose or less verbose but not auto-completion and type checking.
This is really sad that microsoft/pyright/issues/8647 is not fixable.

What would you prefer?

[JonathanPlasse]

If we use a union like set[Literal[...]] | set[str], both can be used.
Pyright does not raise any error for the code below.

from typing import Literal


class A:
    def f(self) -> set[Literal["a", "b"]] | set[str]:
        return set()


class B(A):
    def f(self) -> set[Literal["a", "b"]]:
        return {"a"}


class C(A):
    def f(self) -> set[str]:
        return {"a"}


class D(A):
    def f(self):
        return {"a"}

[Andrej730]

Tbh I would prefer just keeping it set[str] or | set[str] but it's probably just me being lazy - the typing should be correct and it should be a set of literals, otherwise it defeats the purpose - e.g. adding | set[str] wouldn't catch errors with wrong return values.

I also thought of some otehr perspective on why using -> set["bpy.types.OperatorReturnItems"] is probably the solution for this - in mypy it seems you can't rely on inherited return type and it will work only if you provide return type in the method explicitly:

import typing


class Operator:
    def execute(
        self, context
    ) -> set[typing.Literal["RUNNING_MODAL", "CANCELLED", "FINISHED", "PASS_THROUGH", "INTERFACE"]]:
        return {"FINISHED"}


class Test(Operator):
    def execute(self, context):
        # doesn't fail
        return {"FINISHED"}
        
class Test2(Operator):
    def execute(self, context):
        # Also doesn't fail
        return {"FINISH"}
        
class Test3(Operator):
    def execute(self, context) -> set[typing.Literal["RUNNING_MODAL", "CANCELLED", "FINISHED", "PASS_THROUGH", "INTERFACE"]]:
        # Finally fail
        return {"FINISH"}

[JonathanPlasse]

With -> set["bpy.types.OperatorReturnItems"]:

• Force to add -> set["bpy.types.OperatorReturnItems"] to all function to avoid Pyright errors
• The return set values are thus always checked.
• This is more verbose

With -> set["bpy.types.OperatorReturnItems"] | set[str]:

• The return type can be left out or be set[str]
• The return set values are not always checked as the user is not force to type the return value
• Only when specifying set["bpy.types.OperatorReturnItems"] will the return set values be checked
• The discoverability of bpy.types.OperatorReturnItems is strongly diminished for new user as it does not generate errors

Both options works for me.
I would prefer -> set["bpy.types.OperatorReturnItems"] as when someone already use a type checker, adding type annotations is expected and would be the more correct type annotation.

[Andrej730]

Agree that more strict version is better.

[nutti]

This discussion is now solved by #300.