Conversation
I've upgraded this to a property, and added basic validation to check the dictionary keys.
The `constraints` property is now a typed dictionary. Assigning dictionary literals to it still ought to work, but it should flag type errors if the keys are incorrect. The method `BaseProperty._validate_constraints` is provided to convert untyped dictionaries with appropriate validation. This now uses `pydantic` to validate the typeddict. It is stricter than what I did before, as it also checks the type of the keys, not just their names. Pydantic was less ugly than coming up with my own logic to coerce an untyped dictionary into a typeddict. I've added a unit test on validation to check it does what I expect. It would be lovely to deduplicate the typeddict and the constant with key names in it - but this is hard to do neatly.
While typing has a TypedDict class from Python 3.8, pydantic requires the use of typing_extensions prior to 3.12.
rwb27
force-pushed
the
validate-constraint-keys
branch
from
fb961c3 to
ec732db
Compare
julianstirling
requested changes
Mar 25, 2026
| ) | ||
| self._constraints: FieldConstraints = {} | ||
| try: | ||
| self.constraints = self._validate_constraints(constraints or {}) |
Contributor
There was a problem hiding this comment.
It would be good to add examples of how to readonly and constraints are set to these docs so it is more discoverable. Otherwise it is only documented in the API for a descriptor which involves getting pretty deep into the weeds of how it works.
| # as metadata if used on the wrong type. We don't currently raise errors | ||
| # for these. | ||
|
|
||
| # We should also raise errors if constraints are set after a property is defined |
Contributor
There was a problem hiding this comment.
I don't understand this comment? We have to set the constraint after the property definition?
| # We should also raise errors if constraints are set after a property is defined | ||
| with pytest.raises(UnsupportedConstraintError): | ||
|
|
||
| class FunctionalBadConstraintThing(lt.Thing): |
Contributor
There was a problem hiding this comment.
Are there any tests of good functional constrains? That seems like a good thing to test that it can be defined as expected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds better validation and typing to
BaseProperty.constraints. This should be particularly helpful for functional properties, where it's likely that this property will be accessed directly, rather than through the constructor.I've changed the type of
BaseProperty.constraintsto be aTypedDict, because it should retain compatibility with existing code that assigns a (valid)dictliteral while also offering type checking and autocompletion in type-aware IDEs. The first commit of this PR implements basic validation without changing any types, the next two swap toTypedDictand usepydanticto validate the dictionary at runtime. This is primarily because converting an untyped dict into a typed one is really ugly, so I'd rather usepydanticthan implement my own converter. Switching validation topydanticalso means we now check the types of the constraints, which is a nice bonus.Closes #275