Allow subclassing from missing dependency#28
Allow subclassing from missing dependency#28ZanSara wants to merge 9 commits intoManderaGeneral:masterfrom
Conversation
Signed-off-by: Mandera <rickard.abraham@gmail.com>
Signed-off-by: Mandera <rickard.abraham@gmail.com>
|
I think this has potential! However I would like subclassing ``FakeModule` to recursively return itself, just like getting an attr of it does! I tried a little bit to make that work but I couldn't. I added a test that I'd like to pass for example (Just one of the many use cases) I added two commits! This is also an experiment on my part, I've never added commits to someone else's PR before. I'm afraid it could be frowned upon. Should I perhaps have credited you in the commit message or not committed at all? I have no idea what the general consensus is, please let me know 😄 |
Same, I wanted to do that too at the start, but I couldn't make it work either 😅 Then I tried to use a plain Don't forget that even if we want to use However, one thing we can do it to make
Thanks! I'll try to make that work too 👍
I don't mind, no problem! The only issue I see is that if I was working on the same files and you committed in the meantime, it could become a mess to merge. So normally when I commit on someone's PR I make sure they're not actively working on it and I announce it before doing it, just to avoid that situation. As long as it's just us two I don't really mind though 😄 |
# Conflicts: # generalimport/fake_module.py # generalimport/test/test_generalimport.py # generalimport/test/test_usage/test_object.py
Expecting test_subclass_class_returning_self to fail
|
Dev workflow is functional! The test I added is failing here. I am leaving this for now, taking a closer look later! |
|
Is there any update on this pull request? This generalimport library is super useful, but I really need this subclassing functionality |
|
Hey there, I'm glad you find it useful! |
Fixes #27
This PR adds an implementation of
__mro_entries__toFakeModule. This method returns a "FakeBaseClass" class whose__init__(and__new__, for good measure) trigger aMissingOptionalDependencyexception. In this way, subclasses from missing dependencies can be created, but will fail as soon as they're initialized. See the unit test.Note: overriding
__init__might not be necessary but I don't see downsides of doing so right now. Let me know if you prefer to stick to__new__only.