Rework "context" interface #62
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pp-mo
commented
Jul 1, 2020
| @@ -499,7 +514,7 @@ def test_nop(self): | |||
| def test_active_str(self): | |||
| client = "client" | |||
| pre = self.copy() | |||
| with self.lenient.context(active=client): | |||
| with self.lenient.context(client): | |||
| @@ -513,7 +528,7 @@ def client(): | |||
| pass | |||
|
|
|||
| pre = self.copy() | |||
| with self.lenient.context(active=client): | |||
| with self.lenient.context(client): | |||
|
|
||
| def test_args_str(self): | ||
| client = "client" | ||
| services = ("service1", "service2") | ||
| pre = self.copy() | ||
| with self.lenient.context(*services, active=client): | ||
| with self.lenient.context(client, services): |
| @@ -562,30 +579,168 @@ def service2(): | |||
| client = "client" | |||
| services = (service1, service2) | |||
| pre = self.copy() | |||
| with self.lenient.context(*services, active=client): | |||
| with self.lenient.context(client, services): | |||
| client = "client" | ||
| services = ("service1", "service2") | ||
| pre = self.copy() | ||
| with self.lenient.context(client, service1=True, service2=True): |
There was a problem hiding this comment.
NOTE: new syntax / capability
| # Note: use dict for the keywords, as qualnames are really long ! | ||
| settings = {qualname1: True, qualname2: False} | ||
|
|
||
| with self.lenient.context("client", **settings): |
There was a problem hiding this comment.
NOTE: new syntax / capability
|
|
||
| client_settings = dict(svc1=True, svc2=False, svc3="seven", svc4=-5.3) | ||
|
|
||
| @lenient_client(services=client_settings) |
There was a problem hiding this comment.
NOTE: new syntax / capability
| def test_setting_modify(self): | ||
| pre = self.copy() | ||
|
|
||
| with self.lenient.context("client", set1=1, set2=2): |
There was a problem hiding this comment.
NOTE: new syntax / capability
26 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Modified to allow settings updates to accommodate non-binary settings values, and making the service names valid as keywords.
This means you can create an (inner) context in which a existing binary-type service is turned "off".
It also supports client value settings with "service_name=control_value"
So, this replaces
context(*services, active=client)withcontext(client, services)But it also allows :
services (list of callable or name)still works. Now equivalent to{svc:True for svc in services}**kwargsform allows e.g.context(svc1=True, svc2=True)as alternative tocontext(services=(svc1, svc2)context(client, **services_dict)is same ascontext(client, services_dict)Own review below illustrates the key changes by highlighting the modified
contextusages intests/unit/common/lenient/test_Lenient.pyTODO: probably more tests for the new stuff
BIG NOTE:
For this, I have re-implemented the basic settings in the
Lenient.__dict__, replacing tuples of names with a set of (key, value) pairs.However, I only did this because I wasn't clear why a tuple is used at present
-- whether for efficiency or so it is hashable.
-- the existing comments do make clear that order is not supposed to matter.
If these factors are not essential, it would still be much nicer to just use dictionaries.
This was all a bit of a pain with the tests, because they all work via implementation details (checking the dict) instead of some public access 😓
But it could be changed again if needed, without too much grief ... Really. Dictionaries would definitely be more natural.