Interface Ambiguity and Type Degradation
Attempting to support both synchronous and asynchronous execution through a unified entry point (ImednetSDK with an enable_async=True flag) destroys static type checking. If the sync and async clients share the same endpoint classes (e.g., sdk.records), modern IDEs and tools like mypy cannot accurately predict the return type. Developers will be constantly uncertain whether a method call returns a standard object or an unawaited coroutine.
Actionable Solution: Strictly bifurcate the synchronous and asynchronous API surfaces. Create entirely separate endpoint classes (e.g., AsyncRecordsEndpoint) and map them exclusively to the AsyncImednetSDK. A method must return either a data object or a coroutine, never a dynamic switch between the two based on a hidden initialization flag.
Interface Ambiguity and Type Degradation
Attempting to support both synchronous and asynchronous execution through a unified entry point (ImednetSDK with an enable_async=True flag) destroys static type checking. If the sync and async clients share the same endpoint classes (e.g., sdk.records), modern IDEs and tools like mypy cannot accurately predict the return type. Developers will be constantly uncertain whether a method call returns a standard object or an unawaited coroutine.
Actionable Solution: Strictly bifurcate the synchronous and asynchronous API surfaces. Create entirely separate endpoint classes (e.g., AsyncRecordsEndpoint) and map them exclusively to the AsyncImednetSDK. A method must return either a data object or a coroutine, never a dynamic switch between the two based on a hidden initialization flag.