@Marvin - is

Variable.get

supposed to be async? If I just call

Variable.get('name')

and then try and use the value (which is a dictionary) I get:

TypeError: 'coroutine' object is not subscriptable

. If I add the

await

on the

.get

call it works, but I get a typing error in pyright as it does not claim to be awaitable in the type hinting.

The

Variable.get

method in Prefect is indeed designed to be compatible with both synchronous and asynchronous contexts due to the use of the

@sync_compatible

decorator. This means that if you call it in a synchronous context, it should behave like a regular function, but if you call it in an asynchronous context, you need to

await

it. Here's the catch: the type hinting for

Variable.get

has been reported to be incorrect. It suggests that the method is not awaitable, which leads to confusion when using type checkers like Pyright. This is a known issue and has been discussed in GitHub issues. For now, if you're using it in an asynchronous context, you should continue to use

await Variable.get(...)

, and you might need to ignore the type checker warnings until the type hints are corrected in future releases. For further details, please refer to the related GitHub issue and the documentation on this topic.

Yeah, that's largely correct. One thing Marvin doesn't mention is that there are explicit async methods for good typing, like

aget

more context: https://github.com/PrefectHQ/prefect/issues/15008

I must not have a latest enough version for

aget

. Is the long term plan to still make

.get

async if the inferred context is async?

no. we want explicit sync / async methods

.get

async if the inferred context is async?

this ^ is how it has been, which has caused a lot of confusion over time for now, if you want to opt out of the dual contextual behavior, you can pass

_sync=true

to the get method

Gotcha, thanks. +1000 for only asyncing if

.aget

is called

yep, prefect 2.x introduced this so to avoid massive breaking changes we had to keep it at least until the new explicit methods are gtg

hey 👋 when trying to await a variable I'm wondering if adding overload annotations here would help our type checker understand the sync/ async usage pattern?

hey @Serina G! unfortunately we've tried several versions of overloads with sync_compatible to no avail (they all make different concessions) I would say for type safety you need to use the explicit method (

aget

in this case) which means you need to be on a version where that's implemented things should be type safe once we've finished then explicit methods and then pass through the deprecation window (after which we'll totally remove sync_compatible)

ah, makes sense thanks!