Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename HarborAsyncClient to HarborClient #8

Open
pederhan opened this issue Nov 29, 2022 · 1 comment
Open

Rename HarborAsyncClient to HarborClient #8

pederhan opened this issue Nov 29, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@pederhan
Copy link
Member

harborapi is first and foremost and async package, and as such the main client implementation shouldn't need "Async" tacked onto its name. Having the names HarborAsyncClient and HarborSyncClient is a bit of an eyesore, and it would be better to have HarborClient and HarborSyncClient to denote that the async client is the primary implementation and that the sync client is a modification of the original async client.

In order to not break the installations of current users (all 0 of them), the harborapi and harborapi.client modules should provide HarborClient AND HarborAsyncClient, but with a deprecation warning issued for the latter.

We will need to add some sort of import hook, or perhaps create HarborAsyncClient by subclassing HarborClient and issuing a warning in the constructor:

import warnings

class HarborAsyncClient(HarborClient):
    def __init__(self, *args, **kwargs) -> None:
        super().__init__(*args, **kwargs)
        warnings.warn("HarborAsyncClient is deprecated and will be removed, use HarborClient instead.", DeprecationWarning)

This will of course break IDE auto-completion for the __init__ function of HarborAsyncClient, but that fact combined with the warning should make people switch over to HarborClient.

@pederhan pederhan added the enhancement New feature or request label Nov 29, 2022
@pederhan
Copy link
Member Author

pederhan commented Jan 25, 2023

Instead of subclassing, we could probably just modify the __new__ method of this hypothetical HarborAsyncClient to return HarborClient instead, so no matter which one you try to instantiate, you always get the same type.

I mean, yeah, a subclassed HarborAsyncClient would pass any isinstance checks for HarborClient but, it's probably better to not introduce a whole new type that can mess things up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant