8000 Added decorators for checking values of input to property setters (Issue-38) by LGraber · Pull Request #46 · tableau/server-client-python · GitHub
[go: up one dir, main page]

Skip to content

Added decorators for checking values of input to property setters (Issue-38) #46

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

Merged
merged 8 commits into from
Sep 30, 2016

Conversation

LGraber
Copy link
Contributor
@LGraber LGraber commented Sep 29, 2016

No description provided.

@@ -1,5 +1,6 @@
import xml.etree.ElementTree as ET
from .exceptions import UnpopulatedPropertyError
from .property_decorators import property_not_nullable
Copy link
Collaborator

Choose a reason for hiding this comment

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

At first glance the code feels ok, but I think there might be a better name than "property_decorator" which both have meanings of their own.

I'll do a more detailed review in a bit

Copy link
Contributor
@graysonarts graysonarts left a comment

Choose a reason for hiding this comment

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

I'm okay with the name. They are decorators for properties. The only other name I could possible see is "property_constraint" or something similar.

@t8y8
Copy link
Collaborator
t8y8 commented Sep 29, 2016

I prefer the decorator having a name that indicates it's intent and not the fact that it happens to be testing properties or is a decorator :) I'm not a stickler but it'll make it easier to understand down the road.

@validate_schema or @validate_model or something like that feels much closer to what it does.

The second question is can we do a single decorator that takes in parameters on what it validates (Django Forms, I believe, is similar to this)

@validate_model(enum=Auth, is_null=False)

It makes the decorator explosion a little more manageable.

@graysonarts
Copy link
Contributor

I'd much rather the individual decorators than one über one. If we have a single one, then we have to account for all possible combinations. That's error prone. If we have multiple decorators, we can compose them into whatever combination we need.

8000

@LGraber
Copy link
Contributor Author
LGraber commented Sep 29, 2016

I also prefer the individual decorators. I tried writing one but as Russell pointed out it ended up being an explosion and not nearly as easy to read.

@t8y8
Copy link
Collaborator
t8y8 commented Sep 29, 2016

Fair point on wanting them to be composable -- I think that can be done without having an uber method though.

Django does it by having one decorator that takes a list of functions and that does the validation for the model by applying those functions.

So for us it could be:

@validate_model(validators=[is_not_nullable, is_right_type(Auth)])
def function():
    pass

Each function is the composable set of checks we've got today, and if we add more in the future it's a little easier to control the order in which the validations are applied -- and not make functions look giant.

@a
@b
@c
@d.setter
def happy_days():
    pass

@LGraber
Copy link
Contributor Author
LGraber commented Sep 29, 2016

Order is not so important except to make sure the setter is first (still an issue in yours).

Copy link
Collaborator
@t8y8 t8y8 left a comment

Choose a reason for hiding this comment

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

🚀 per our conversation in person!

(Remember to squash and merge, I think I know why it was acting funny before)

@LGraber LGraber merged commit 56af4af into development Sep 30, 2016
@LGraber LGraber deleted the issue-38 branch September 30, 2016 17:59
bryceglarsen pushed a commit to bryceglarsen/server-client-python that referenced this pull request Dec 28, 2023
…ableau#45)

Fixes tableau#42 tableau#46 
* Initial attempt at enabling reading the columns from the datasource
* Fixing pep8 errors for EOFEOL
* Changing to OrderedDict for getting columns
* Add documentation for the various column attributes
* rename column to field
* Fixed tableau#46 encode apostrophes in field names
* Enable multilook up for Fields
* Rename properties on the field based on feedback given in tableau#45
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.

3 participants
0