A few issues with Maybe

[Corentin-Bravo]

I've started migrating my application from using UNSET to using Maybe only.

I met a few annoyances which I thought would be nice to be discussed before creating issues. I put them in a rough order of how much I care about.

• Maybe is incorrectly defined in the type checking block.
  It should be Maybe[T]: TypeAlias = Union[Some[T], None] so that Maybe is considered a Generic for mypy.
  Why that matters?

@strawberry.input
class MyInput:
     datetime_field: Maybe[datetime] = field(graphql_type=Maybe[MyCustomDatetime])

Will not be accepted by mypy with the current implementation (as of mypy 1.16.1 and strawberry 0.280).
error: Type application is only supported for generic classes [misc]

• Maybe always allows Some(None) value

@strawberry.input
class MyInput:
    attr: Maybe[str]

def my_route(info: Info, inputs: MyInput) -> bool:
   return True

@strawberry.type
class Mutation:
    my_route = strawberry.mutation(resolver=my_route)

# I skip how the client is created and how the schema is defined for brievity
res = client.post("/graphql", json={'operationName': 'rIuQiyGjEoFTSzR', 'query': 'mutation rIuQiyGjEoFTSzR ($inputs: MyInput!) {
    myRoute (inputs: $inputs) {}
', 'variables': {'inputs': {'attr': None}}})
assert res.status_code == 200
assert res.json()["data"]["myRoute"] is True

I'm fairly certain that it was explicitly intended that this should not happen. Was I wrong?

• Maybe does not have its default value injected when used as a custom graphql_type. In the same example as above, if I do not provide datetime_field the input will not work.
  If I want the input to work as expected I must do:

@strawberry.input
class MyInput:
     datetime_field: Maybe[datetime] = field(graphql_type=Maybe[MyCustomDatetime], default=None)

• Mypy does not see Maybe as a field with default.

@strawberry.input
class MyInput:
    attr: Maybe[str]


k = MyInput()

Will have mypy complaining with:
error: Missing named argument "attr" for "MyInput"

• Some behaves annoyingly with Union

def call_some(some_value: Some[int] | Some[None]]) -> None: ...
k: int | None = None

call_some(Some(k))

mypy will complain with
Argument 1 to "call_some" has incompatible type "Some[int | None]"; expected "Some[int] | Some[None]"

It's slightly frustrating, because Some[int] | Some[None] is basically the same as Some[int | None].
I could see it being a "feature" to encourage people to unwrap their Some within the route and not propagate them everywhere in the code.

But I found it slightly frustrating so I thought I'd point it out.

• None is ambiguous now.
  I used to have functions that took in inputs some values (that could be T, None or UnsetType) and did things depending on them.
  Those functions cannot work anymore because None without context is ambiguous. The function has no way to know if it's a None from a Maybe, a None from a Some[StrawberryOptional] or a None from a StrawberryOptional.

For example

@overload
def parse_string(string: str, case_fn: Callable[[str], str] | None) -> str: ...
@overload
def parse_string(string: None, case_fn: Callable[[str], str] | None) -> None: ...
@overload
def parse_string(string: UnsetType, case_fn: Callable[[str], str] | None) -> UnsetType: ...
def parse_string(string: T, case_fn: Callable[[str], str] | None) -> T
    if isinstance(string, UnsetType) or string is None:
        return string
    else:
        stripped_string = string.strip()
        if case_fn:
            return case_fn(stripped_string)
        else:
            return stripped_string
# This class is then inherited by both the Create and Update inputs so that the same parsing and validation is done on both inputs
@strawberry.input:
class IdentityMixin:
    first_name: str | UnsetType
    last_name: str | UnsetType
    email: str | UnsetType | None
    phone_number: str | UnsetType | None
    def parse(self) -> None:
        self.first_name = parse_string(self.first_name, case_fn=str.lower)
        self.last_name = parse_string(self.last_name, case_fn=str.lower)
        if self.first_name == "" or self.last_name == "":
            raise Exception(...)
        self.email = parse_string(self.email, case_fn=str.lower)
        # validate_email is some internal function to determine if an email is valid
        if isinstance(self.email, str) and not validate_email(self.email):
            raise Exception(...)
        self.phone_number = parse_phone_number(self.phone_number)

Using Some does not work well due to the above type-checking issue (You need to have an overload for Some[str], Some[str | None] and you'll want an overload for Some[None] just for completeness, which is a bit too much boilerplate).

Plus considering the Create inputs is likely to NOT have Maybe, while the Update inputs does, it becomes very messy.

I worked around it by creating a partial TypedDict, which helps handling the difference between "undefined" and None. But it lead to less factorization of code, because I have to be careful with Maybe (unwrapping and rewrapping them when needed, and skipping the correct None)

While this is a compilation of my complaints, I will say that it's much more elegant than my solution, and the disappearance of Unset makes the type checking much better overall (with the only slight drawback as I said that the developper must be much more careful around None).