Repository navigation
Add Inequality Comparisons to Rules #701
Description
Activity
I agree. I may attempt to patch that in. It would allow for some useful pre optimization as well (re.compile)
Reacted by Heitor LessaIt would also be nice if the init took a logger and only created one if None was passed.
Maybe this could be combined with feat(feature_flags): add in feature_flags RE_* actions and update tests/docs #692
?- Let’s crate a separate one so it’s easier to know this is a thing for customers reading Changelog/Release notes. I want to accept a Logger instance everywhere in 2.0…On Sat, 25 Sep 2021 at 19:16, Gerald Leter ***@***.***> wrote: Maybe this could be combined with feat(feature_flags): add in feature_flags RE_* actions and update tests/docs #692 <https://github.com/awslabs/aws-lambda-powertools-python/pull/692/files>? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBBSD2AQDYEQYIIJH4TUDZC5FANCNFSM5EXUIYGA> .
Ok, do you want a separate ticket to track "accept a Logger instance everywhere in 2.0"??
Note -- that should not need a major revision roll since if the code looks like the following it is compatiable:
def __init__ (self, logger=None): if logger == none: logger = logging.getLogger(__name__)
Is equivalent.
Reacted by Ran Isenberg@heitorlessa @gwlester When I created the feature, I didnt want to add too many actions right at the beginning but to start with sometihng that covers my basic needs. It's great that people are using it and we should add more actions.
The only concern i have is regarding schema validation here for condition value, should we keep it as it is today - just check that it's not empty, or perhaps enforce more validation in case it's greater than (check int/float etc.). what do you think?and bring your own logger should definitely be supported.
- Only one separate ticket for supporting Logger in the feature flags utility. Feature flags is also beta so I’m not worried in genera as we’ve been waiting for customer feedback to improve it overall…On Sun, 26 Sep 2021 at 00:45, Gerald Leter ***@***.***> wrote: Ok, do you want a separate ticket to track "accept a Logger instance everywhere in 2.0"?? *Note* -- that should not need a major revision roll since if the code looks like the following it is compatiable: def __init__ (self, logger=None): if logger == none: logger = logging.getLogger(__name__) Is equivalent. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBG7HIPANCRQUDTVFF3UDZGJJANCNFSM5EXUIYGA> .
- Reacted by Heitor Lessa
@heitorlessa @gwlester When I created the feature, I didnt want to add too many actions right at the beginning but to start with sometihng that covers my basic needs. It's great that people are using it and we should add more actions. The only concern i have is regarding schema validation here for condition value, should we keep it as it is today - just check that it's not empty, or perhaps enforce more validation in case it's greater than (check int/float etc.). what do you think?
I'd not add any additional checking. An exception today causes a failed condition and that is enough.
I think the conditions need to be named clearer than I suggeted:
- KEY_GREATER_THAN_VALUE
- KEY_GREATER_THAN_OR_EQUAL_VALUE
- KEY_LESS_THAN_VALUE
- KEY_LESS_THAN_OR_EQUAL_VALUE
- KEY_NOT_EQUAL_VALUE
I will attempt to do a Pull Request for the above on 2021.10.01
Reacted by Ran IsenbergI personally don't like how the exception is handled in the case where matching the value of False (which results in True) would match an exception. Not sure if this is intended to allow for exceptions to act this way by design and not disrupt the process.
@heitorlessa, done see Allow bring your own logger to Feature Flags #702
Thanks a lot for that - I've just made the necessary changes and merged it.
@heitorlessa, will this one make next week's release?
If anyone could help getting the tests and merge conflicts in place by Monday EOD, yep it will ;-)
Tests and conflicts are done.
@heitorlessa -- I think this should have the label: status/staged-next-release
- Yes! Added earlier but was offline - all good to be released either tomorrow or Wed the latest…On Mon, 4 Oct 2021 at 15:14, Gerald Leter ***@***.***> wrote: @heitorlessa <https://github.com/heitorlessa> -- I think this should have the label: *status/staged-next-release* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBDMR2BJ62KETTM3MPDUFGSDNANCNFSM5EXUIYGA> .
This is now available as part of today's 1.21.0 release -- Thank you for the contribution, credits given at the top ;)
https://github.com/awslabs/aws-lambda-powertools-python/releases/tag/v1.21.0
Is your feature request related to a problem? Please describe.
It would be helpful to be able to compare if something is GREATER_THAN or GREATER_THAN_OR_EQUAL to a value, e.g. if the current timestamp is greater a particular timestamp.
Describe the solution you'd like
Add the following to the comparison operators:
Alternatively, provide a documented way to add custom (i.e. user-supplied) conditions to the mapping_by_action set used in _match_by_action.
Describe alternatives you've considered
Additional context