https://flyte.org logo
Join Slack
Powered by
Has anyone noticed behavior where mypy doesn't cat...
# ask-the-community
r
Has anyone noticed behavior where mypy doesn't catch invalid usages inside `@flytekit.task`/`@flytekit.dynamic`? We have a clear case w/ a missing positional argument that we'd typically expect the type-checker to catch, but it seems like the decorator may be causing some unintended behavior here?
k
Interesting, this is something we probably as community need to work on is adding mypy complexity to flytekit
r
I noticed this issue elsewhere in our codebase (outside of Flyte), seems like there's something with how the `@task`/`@workflow` decorators work that's preventing mypy from performing proper validation
e
@Rahul Mehta, can you share an example of this invalid usage? What does 
reveal_type
say?
r
reveal_type
on which object/function?
We've encountered this on something as basic as this:
Copy code
@flytekit.task()
def compute_stats(data: List[int]) -> Result:
    """Compute summary stats"""
    return Result(
        mean=statistics.mean(data),
        median=statistics.median(data),
        stdev=statistics.stdev(data),
    )


@flytekit.task()
def generate_data(n_elements: int, random_min: int, random_max: int) -> List[int]:
    """Generate dummy data"""
    return [random.randint(random_min, random_max) for _ in range(n_elements)]


@flytekit.workflow()
def simple_workflow(n_elements: float = 100, random_min: int = 0, random_max: int = 10) -> Result:
    """Generate random data & compute basic summary statistics"""
    data = generate_data(n_elements=n_elements, random_min=random_min, random_max=random_max)
    return compute_stats(data=data)
Where the 
n_elements
arg in 
generate_data
expects an 
int
, but we're passing in a 
float
. Mypy passes on this, and fails when I remove the `@task`/`@workflow` decorators
This only seems to be happening with arguments to functions that were decorated w/ 
@task
or 
@dynamic
-- type errors inside task implementations are caught as expected
e
Got it. Thanks. Just so I understand, this is specific to the default argument, right? In any case, this is a bug. I'll open a gh issue to track this. This repros the issue:
Copy code
import typing
from typing_extensions import reveal_type

from flytekit import task, workflow

@task
def t(n: int) -> int:
    return n

@workflow
def wf(n: float = 100) -> int:
    return t(n=n)
r
This isn't just specific to the default arg; thanks for tracking that
e
sure. You want to tighten the feedback loop, right? Because you'd see this error when serializing the workflows+tasks
r
Right, we'd ideally be able to catch these w/ our basic type checking (running that + the linters is a common part of our iteration loop). The complication in 
@dynamic
workflows is that this would only get surfaced at runtime / not during serialization, but if mypy type checking worked that'd help us ease the friction of working w/ dynamic workflows a ton
160 Views
Open in Slack
PreviousNext
Powered by