feat: Exposes types if they are explicitly declared by the user

[dmadisetti]

📝 Summary

myvar: int = 0

@app.cell
def foo(myvar: int) -> tuple[int]:
    defvar: int = 1
    return (defvar,)

on reference or definition, will carry its annotation in the signature

couple other notes:

• I also tried putting in -> None for blank returns, but it looks like a pretty noisy change.
• I'm not a huge fan of the return type because an actual call to the function doesn't return those values.
• Return signature only occurs when all the variables are signed
• types which cannot be properly resolved are coerced to strings in signatures

@akshayka

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
marimo-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 29, 2025 5:31pm

[dmadisetti]

or

Maybe we define the type alias:

Edges: TypeAlias = tuple[Any, ...] | ActualReturnType

@app.cell
def foo(myvar: int) -> marimo.Edges:
    ...

I think the ActualReturnType is HTML output right now

[akshayka]

The signature for arguments looks good! Nice surgical change, too.

If you are unsure about the return signature, how about we only add types for arguments right now?

[dmadisetti]

Thanks! So call just returns the value from run which gets processed by mime, but maybe ideally it should be the raw value (I'd argue this for run as well)

the alias would then maybe be better as

marimo.Output[type] # are generics supported in 3.9?

But I don't think return type are all that important. For some reason, linters don't ask for return types on decorated pytests- I wonder what their decorators do that suppresses it

[akshayka]

Looks great — not sure what's going on with CI though?

[github-actions]

🚀 Development release published. You may be able to view the changes at https://marimo.app?v=0.13.3-dev42