Rework "context" interface #62
Closed
Conversation
This file contains hidden or 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
Owner
Author
pp-mo
left a comment
pp-mo
left a comment
There was a problem hiding this comment.
These lines point up the changed syntax new capabilites in the 'context' call
| client = "client" | ||
| pre = self.copy() | ||
| with self.lenient.context(active=client): | ||
| with self.lenient.context(client): |
|
|
||
| pre = self.copy() | ||
| with self.lenient.context(active=client): | ||
| with self.lenient.context(client): |
| services = ("service1", "service2") | ||
| pre = self.copy() | ||
| with self.lenient.context(*services, active=client): | ||
| with self.lenient.context(client, services): |
| 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): |
Owner
Author
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): |
Owner
Author
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) |
Owner
Author
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): |
Owner
Author
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.