evgenyshulman commented on issue #8052: URL: https://github.com/apache/airflow/issues/8052#issuecomment-619564136
> Regarding templating, I understand why you say that now. An option we implemented internally to do this was to add a `map` function to XComArg which is lazy evaluated and that enables transforming the value pulled before passing it to the operator. > > My main worry is enabling the Jinja string is that it may cause some non-expected behavior. For example, what happens when the value is not a string? I rather not enable it mostly because it still can be done using `context['ti'].xcom_pull` if users needed, while not causing errors for users that are just starting to use Airflow. I agree that Jinja + XCom was always problematic, however, most of the time it does work. if object is nonstr -> Jinja will convert it into str as it was doing for any other object coming directly from `xcom_pull`. We can remove __str__ implementation if we have any problems around it before we merge into apache-airflow > > Regarding BaseArg class. I would say no as we are moving the extensibility piece to XCom itself. That should allow injecting custom serialization/deserialization behavior consistently across Airflow and not only XComArg. Can't think of any other reason to overwrite XComArg apart from custom serial/deserial logic. My working assumption is that replacing XCom only is going to be not enough to implement "real" replacement for serialization/deserialization, but.. if I am wrong, we can easily implement that base class. So let's just wait till somebody will do that for real. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
