[GitHub] [airflow] MatrixManAtYrService commented on issue #19884: Type hinted `@task` decorated functions to create typed XComs

[GitBox <gi...@apache.org>]

MatrixManAtYrService commented on issue #19884:
URL: https://github.com/apache/airflow/issues/19884#issuecomment-982787063


   Thanks for your thoughts on this.  I didn't realize that runtime logic based on type hints was frowned upon, but seeing as it's a newer feature I understand the desire to proceed with caution.
   
   @hterik I'm trying to visualize your strategy, specifically when an xcom_pull happens--without relying on the type hint how do we know where to look for those functions?  Do we require`ENABLE_XCOM_PICKLING` and look on the object itself, or do we expect a special field in the json that says "here's my class, go look there for conversion functions"?
   
   ----
   
   re: type checking, this sounds nice:
   >  we should be able to simply (when we implement it) run mypy on the DAGs and there type hints should help DAG writer to develop the DAG.
   
   From my naive point view it seems like that would only require something like [this](https://blog.whtsky.me/tech/2021/decorator-type-gymnastics-in-python/#simple-type-hints-for-simple-decorators) around the decorators, but it looks like [we're already doing something similar](https://github.com/apache/airflow/blob/9a469d813fc083a7a5f402727e93df3e3f9c9118/airflow/decorators/base.py#L230).
   
   Could it be that all we need is minor tweaks to how we already handle hinting around decorators, or would it be more invasive than what I'm thinking?  If it's just the former, I might take a shot at it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org