Implementing a basic AsyncGuard to logically separate out async calls from Guard() into a new client

[wylansford]

Replaces async functionality in the Guard() class with a second class that is solely for Async calls. Any async calls found in Guard are now deprecated

[zsimjee]

1. Can we have AsyncGuard inherit guard and only override the call functions?
2. In AsyncGuard, should all call overloads be Awaitables and marked async on the def?

[wylansford]

1. Can we have AsyncGuard inherit guard and only override the call functions?

Done & fixed.

2. In AsyncGuard, should all call overloads be Awaitables and marked async on the def?

I think this is up to where we want to handle the async management. Right now the _call function calls _call_async which sets the entry point there. Anything from the chain down there needs to be async. I think this is correct. Otherwise, If the call function is async it would be a bit awkward to need the user to manage any async functionality from the outside. With the current setup we will never have to call await on our guard because it's managed fully internally

[CalebCourier]

1. Can we have AsyncGuard inherit guard and only override the call functions?

Done & fixed.

2. In AsyncGuard, should all call overloads be Awaitables and marked async on the def?

I think this is up to where we want to handle the async management. Right now the _call function calls _call_async which sets the entry point there. Anything from the chain down there needs to be async. I think this is correct. Otherwise, If the call function is async it would be a bit awkward to need the user to manage any async functionality from the outside. With the current setup we will never have to call await on our guard because it's managed fully internally

My expectation for an AsyncGuard would be to have to always await both guard() and guard.parse(). This makes it async all the way down. Since we're already throwing when the llm_api isn't async I don't see a reason for maintaining a method signature that allows the user to pass in an incorrect value. With these changes it would also imply that the response itself should be awaitable. This would match the behaviour of other libraries the user would be familiar with like OpenAI: https://github.com/openai/openai-python?tab=readme-ov-file#async-usage

[wylansford]

1. Can we have AsyncGuard inherit guard and only override the call functions?

Done & fixed.

2. In AsyncGuard, should all call overloads be Awaitables and marked async on the def?

I think this is up to where we want to handle the async management. Right now the _call function calls _call_async which sets the entry point there. Anything from the chain down there needs to be async. I think this is correct. Otherwise, If the call function is async it would be a bit awkward to need the user to manage any async functionality from the outside. With the current setup we will never have to call await on our guard because it's managed fully internally

My expectation for an AsyncGuard would be to have to always await both guard() and guard.parse(). This makes it async all the way down. Since we're already throwing when the llm_api isn't async I don't see a reason for maintaining a method signature that allows the user to pass in an incorrect value. With these changes it would also imply that the response itself should be awaitable. This would match the behaviour of other libraries the user would be familiar with like OpenAI: https://github.com/openai/openai-python?tab=readme-ov-file#async-usage

Yeah understood and can agree on that. Conforming to the other llm apis seems good. I just see this as a design preference of abstracting away async or not. Will make this change

[wylansford]

1. Can we have AsyncGuard inherit guard and only override the call functions?

Done & fixed.

2. In AsyncGuard, should all call overloads be Awaitables and marked async on the def?

I think this is up to where we want to handle the async management. Right now the _call function calls _call_async which sets the entry point there. Anything from the chain down there needs to be async. I think this is correct. Otherwise, If the call function is async it would be a bit awkward to need the user to manage any async functionality from the outside. With the current setup we will never have to call await on our guard because it's managed fully internally

My expectation for an AsyncGuard would be to have to always await both guard() and guard.parse(). This makes it async all the way down. Since we're already throwing when the llm_api isn't async I don't see a reason for maintaining a method signature that allows the user to pass in an incorrect value. With these changes it would also imply that the response itself should be awaitable. This would match the behaviour of other libraries the user would be familiar with like OpenAI: https://github.com/openai/openai-python?tab=readme-ov-file#async-usage

Yeah understood and can agree on that. Conforming to the other llm apis seems good. I just see this as a design preference of abstracting away async or not. Will make this change

Change is made and pushed