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

refact(ConditionEvaluator): Simplify condition evaluation #145

Closed
wants to merge 1 commit into from

Conversation

oakbani
Copy link
Contributor

@oakbani oakbani commented Oct 5, 2018

Python SDK as of now, has a bit complex condition evaluation. Before modifying evaluator for audience match type work, this simplifies the condition evaluator and makes it more like how it's done in Ruby, PHP.

Currently, In python we have conditions list and structure.
The structure stores decoded conditions string with { } replaced by an integer placeholder.
And the conditions list is a list of those replaced { } conditions.
This PR removes this undesired complexity. And directly decodes conditions string as in other SDKs.
This will make audience type work easier, where we will be checking match type/ attribute types. etc.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0003%) to 99.662% when pulling ecaa4de on oakbani/refact-evaluator into af38afb on master.

4 similar comments
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0003%) to 99.662% when pulling ecaa4de on oakbani/refact-evaluator into af38afb on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0003%) to 99.662% when pulling ecaa4de on oakbani/refact-evaluator into af38afb on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0003%) to 99.662% when pulling ecaa4de on oakbani/refact-evaluator into af38afb on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0003%) to 99.662% when pulling ecaa4de on oakbani/refact-evaluator into af38afb on master.

@aliabbasrizvi
Copy link
Contributor

Can you elaborate as to why this change is needed at the moment?

My only hesitance is that this has been around for a while and not worth changing in light of the changes we will be making in the near term. This same structure/list paradigm will be useful when we do boolean audiences.

@msohailhussain
Copy link
Contributor

@aliabbasrizvi It's very true, @thomaszurkan-optimizely had the same comment in a discussion for boolean audiences for this approach. But to align with other SDKs, we wanted to make this change. I can discuss in-person tomorrow. @mikeng13

Copy link
Contributor

@aliabbasrizvi aliabbasrizvi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msohailhussain and I discussed and I think we are not going to pursue this at the moment.

Going to request changes on this. I think we can close this out.

@aliabbasrizvi
Copy link
Contributor

Going to close this as previously mentioned.

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

Successfully merging this pull request may close these issues.

None yet

4 participants