m1racoli commented on PR #47326: URL: https://github.com/apache/airflow/pull/47326#issuecomment-2699304219
> I really don't have enough background with python's async implementation to make the call. > > IMHO, I'd prefer to see a breaking implementation change that allows users to use `hook.conn.foo()` and `hook.async_conn.foo()` instead of having to remember that sync calls are `` hook.conn.foo()`` and async calls are ``hook.get_async_conn().foo()` > > Let's see what others think. I have the opinions but not the practical experience with this particular issue, so I suppose they aren't worth all that much in the end. :P I do get your intentions. :) But I fear that this might not be possible. In particular `hook.async_conn.foo()` will be impossible (without some black magic putting an async wrapper around a maybe-init boto3 client), because getting to `async_conn` requires IO which needs to be awaited before you can even get to `foo`. The issue is `@property` and `@cached_propery` obfuscate a lot of work away from the user. This can be nice, because now you can just access a property and everything falls into place. But it also fails to communicate that the thing we want actually requires some work to be done. You can get away with it in normal (sync) code, but in `async` this obfuscation becomes a liability, because `async` requires async all they way down to the actual awaitable IO call (or at least some way of awaitable delegation to a different thread, like we do it with `sync_to_async`) and clearly defined breakpoints (await). This makes sync generally not play nice inside async code and also affects how async code usually is being used. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
