You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's begin by defining a repository pattern that defines a simple CRUD behaviour, allowing to persist a given resource
classIRepository(Generic[T], ABC):
@abstractmethoddefcreate(self, item: T): ->T ...
@abstractmethoddefread(self, id:str): ->T ...
@abstractmethoddefupdate(self, item:T)->T: ...
@abstractmethoddefdelete(self, id:str)->None: ...
classIPersonRepo(IRepository[Person]):
"""Allows CRUD over persons plus some complex persistence use cases"""classIBookRepo(IRepository[Book]):
"""Allows CRUD over books plus some complex persistence use cases"""
Then, let's say that the app uses different implementations of those interfaces depending on the environment. So to keep it clean and steady, we provide a simple factory that provides the appropriate instance given the context.
I could find this error associated in #5374 with a clear answer from @ilevkivskyi stating that this shall be forbidden.
I assume that the issue here is the fact that it makes it very unsafe to instantiate a given type if it is allowed to pass abstract classes, I have no objections here.
But it would be nice to still allow this kind of factory pattern that decouples interfaces and implementations.
I'm thinking that we could provide a allow_abstract inside TypeVar, as in TRepo=TypeVar("TRepo", bound=IRepository, allow_abstract=True), so get_repo can freely receive abstract types and return a concrete implementation ?
The text was updated successfully, but these errors were encountered:
A possible way can be to have something like AbstractType[T] in mypy_extensions which you can't instantiate, but where you can pass abstract classes. I am however not sure this is really worth it now that we have a dedicate error code for this error. You can just do --disable-error-code=type-abstract
I tough about AbstractType as well but it seems a tiny bit overkill as this will only serve for one purpose: factories/service locators.
I did not realise this was under a special error code. This could be enough, granted that we are sure enough that we will not introduce bugs in other use case protected by this check.
Feature
Let's begin by defining a repository pattern that defines a simple CRUD behaviour, allowing to persist a given resource
Then, let's say that the app uses different implementations of those interfaces depending on the environment. So to keep it clean and steady, we provide a simple factory that provides the appropriate instance given the context.
Then, once the app setup is done, in the use case we can ask for the repository and start using it. But alas we are stuck here
Pitch
I could find this error associated in #5374 with a clear answer from @ilevkivskyi stating that this shall be forbidden.
I assume that the issue here is the fact that it makes it very unsafe to instantiate a given type if it is allowed to pass abstract classes, I have no objections here.
But it would be nice to still allow this kind of factory pattern that decouples interfaces and implementations.
I'm thinking that we could provide a
allow_abstract
insideTypeVar
, as inTRepo=TypeVar("TRepo", bound=IRepository, allow_abstract=True)
, soget_repo
can freely receive abstract types and return a concrete implementation ?The text was updated successfully, but these errors were encountered: