Skip to content

Added support for default values in Inclusive schemas#382

Merged
alecthomas merged 3 commits intoalecthomas:masterfrom
nickovs:inclusive-defaults
Feb 17, 2019
Merged

Added support for default values in Inclusive schemas#382
alecthomas merged 3 commits intoalecthomas:masterfrom
nickovs:inclusive-defaults

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!


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.

4 participants