https://prefect.io logo
Join Slack
Powered by
Hi everyone - my company is evaluating prefect, an...
# ask-community
l
Hi everyone - my company is evaluating prefect, and have a question about static typing (pyright). It appears to me that if you have a function defined with some input parameters, the 
@task
annotation will hide those parameters from the typechecker. e.g., this code will not throw an error:
Copy code
@task
def example_task(b: bool):
  return False

@flow
def example_flow():
  return example_task()
Is this expected behavior? Did I misconfigure something?
n
hi @Lucas this looks like something we could potentially fix in the SDK, will post an update here
so, there's a fundamental issue that we'll need a major release to justify changing (it will be a significant breaking change) which is that 
__call__
has 
return_state: bool
between 
*args
and 
**kwargs
which breaks 
ParamSpec
. i think was able to reorganize the overloads to preserve type completeness when you don't use 
return_state
, but as this issue mentions, in prefect's next major version we should remove 
return_state
as a kwarg and instead have an explicit method to return the state instead of the result
l
Ok, that is probably going to make it so that we cannot adopt prefect in its current state - I don't think I can justify breaking type checking across our repo
Is there an earlier version we could use?
Yeah, I did see that github thread from my preliminary investigation. > orgs who have super strict typing reqs encapsulate specific typing issues w utils and add specific ignores could you elaborate on this? How might I go about making this particular 
@task
issue typesafe? I would rather not define parallel public/private functions for all tasks, which was my first thought
n
well first as i mention in 19459, if you don't use the problematic kwarg 
return_state
then the overload change i just made should address your type issue. lmk if you checkout the branch and you're seeing something different for places where there are rather unavoidable type issues (like https://github.com/PrefectHQ/prefect/issues/15008 in the few cases this still exists) then yea its type ignores and private/public encapsulation to minimize type ignores, which is the same thing we do for upstreams that aren't type safe
just to clarify > I don't think I can justify breaking type checking across our repo when i say "type ignores" i mean the type ignore comment on specific lines where you're calling badly typed code
👍 2
l
Is your suggestion to fork on 17388 until the next major deploy? Will that be compatible with the prefect cloud?
n
no sorry i just mean until the next patch release of 
prefect
the SDK which will be tomorrow!
l
Oh, perfect lol
n
and i just meant you can temporarily checkout the branch via 
uv
and see if it fixes your type issue https://blog.zzstoatzz.io/running-list-of-repros-via-uv/ https://github.com/zzstoatzz/typsht
l
Yeah, that makes sense
Ok, just didn't know how long your major version SDK release cadence was
If that's fixed soon, sgtm! Thanks for the help
catjam 1
n
just to update - that fix is merged and the release (3.6.3) will be going out tomorrow (instead of today) in part due to the gh outage
🙌 1
l
Yeah, cloudflare really did a number on the internet
📠 1
n
3.6.3 is now released with the the above PR, lmk if you're continuing to see unexpected weirdness
l
Thanks!
This is working for me now! Thanks @Nate!
11 Views
Open in Slack
PreviousNext
Powered by