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

Added support for default values in Inclusive schemas #382

Merged
merged 3 commits into from Feb 17, 2019

Conversation

nickovs
Copy link
Contributor

@nickovs nickovs commented Feb 10, 2019

This is a trivial implementation of a fix for #381.

@coveralls
Copy link

coveralls commented Feb 10, 2019

Coverage Status

Coverage remained the same at 95.404% when pulling d6e83a6 on nickovs:inclusive-defaults into 806d1c5 on alecthomas:master.

@svisser
Copy link
Collaborator

svisser commented Feb 12, 2019

It's a trivial change but I think there should be a test case to ensure that this is automatically tested and continues to behave as expected.

@nickovs
Copy link
Contributor Author

nickovs commented Feb 12, 2019

I did think about that. Right now there is no test case for Inclusive at all other than checking that the description works (the same goes for Exclusive. If I get a moment I'll look at writing a test suite for them both.

@nickovs
Copy link
Contributor Author

nickovs commented Feb 12, 2019

@svisser I created a set of new tests for both Inclusive and Exclusive, for the input cases of an empty input, one of the variables and all of the variables, with and without default values for the Inclusive case.

@svisser
Copy link
Collaborator

svisser commented Feb 14, 2019

It seems a useful change to make to me.

Given that it's new functionality, I wonder if @alecthomas has an opinion on this?

Copy link
Owner

@alecthomas alecthomas left a comment

Choose a reason for hiding this comment

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

LGTM with one minor change, thanks!

@@ -1127,8 +1127,10 @@ class Inclusive(Optional):
True
"""

def __init__(self, schema, group_of_inclusion, msg=None, description=None):
def __init__(self, schema, group_of_inclusion,
msg=None, default=UNDEFINED, description=None):
Copy link
Owner

Choose a reason for hiding this comment

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

Add new parameters at the end to avoid unnecessary breakage.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK. I put them in that order because that is the order used by both Required and Optional (which is its parent class) but I'm happy either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've pushed d6e83a6 to address this. Reordering the arguments is the only thing that commit does, so If you decide that consistency with the other classes is more compelling than consistency with the part then feel fee to ignore it.

Copy link
Owner

Choose a reason for hiding this comment

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

Ah understood, but still I think avoiding potential breakage is preferable.

@alecthomas alecthomas merged commit bb4e4bf into alecthomas:master Feb 17, 2019
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