-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add validation for number of datetimes in Temporal.interval
#17
base: main
Are you sure you want to change the base?
Conversation
I appear to get an error in IntelliJ on the use of |
Thanks for this draft PR. You probably need to add this snippet to make Python 3.8 happy:
|
My impression (maybe wrong!) is that Or is there a specific preference to use this approach? Happy to do so if there is! |
Ah! Didn't know this :) I guess I don't mind either way too much. Maybe the version check is a bit more explicit, but yours is fine as well. Could you still add the test for a failing validation case? |
Got some time set aside this afternoon to wrap up this PR. I don't want to block the 0.6.0 release much longer! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #17 +/- ##
==========================================
+ Coverage 98.02% 98.05% +0.02%
==========================================
Files 10 10
Lines 203 206 +3
==========================================
+ Hits 199 202 +3
Misses 4 4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@PaulVanSchayck, this PR is ready for review when you have a spare minute. I've added one bad test case for the validation logic, with a temporal interval that contains a single datetime (rather than a pair). Is this satisfactory for what we'd like to cover in our tests? The successful tests cases already exist in the repo and cover instances where a pair of datetimes are provided as the interval. I've actually added another commit that refactors the interval length validation so we can actually unit test how the Pydantic validation logic is configured. Is this overkill, or a suitable approach for testing the logic works as intended? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this testing logic should be in a separate file (rather than test_edr.py
) because that file is focused on the different happy/error test cases represented as JSON files.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle I agree, but I don't think these specific tests are needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for completing this!
A couple of small comments.
from pydantic import AwareDatetime | ||
from typing_extensions import Annotated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is typing_extensions
an externel dependency or not. It is not clear to me from the docs.
Should we make it explicit we are using this by adding it to dependencies
in pyproject.toml
, instead of relying on pydantic to install it for us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should just do the same as pydantic does?
https://github.com/pydantic/pydantic/blob/main/pyproject.toml#L46
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest that because pydantic installs it for us, and this library is so closely coupled to pydantic, then maybe we don't need to be explicit about it? We'd also be able to just use the version provided by pydantic, rather than possibly bringing in two versions of typing_extensions
.
Although, I'm happy to install explicitly as pydantic does, if that's the desired approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to explicitly mention packages that you import, as there is no guarantee that pydantic
will keep using/providing it.
I think there can only be one version of a package in a specific Python environment, and that consistency in the requirements is checked during installation. So as long as we use a greater then package requirement, it should always work. Specifically, if we use typing-extensions>=4.12.2
, we should be good.
class Temporal(EdrBaseModel): | ||
# TODO: Validate this list has two items (C.7. Temporal Object) | ||
interval: List[List[AwareDatetime]] | ||
interval: List[Annotated[List[AwareDatetime], IntervalLen]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why define IntervalLen
instead of using the Len(...)
in-place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see, for testing purposes.
assert IntervalLen.min_length == 2, "Temporal intervals must have at least 2 items" | ||
assert IntervalLen.max_length == 2, "Temporal intervals must have at most 2 items" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am probably missing something, but it feels like you are testing that Python can set a class member...
I much prefer the approach with temporal-interval.json
. Why not add a test there with 3 elements to ensure that both lower and upper bound are unchanged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see now you already mention this in your comments.
As you can see from my comment above, I think this is overkill...
Addresses and resolves the existing
TODO
comment for validating temporal list lengths.Currently, the
interval
field of theTemporal
data class doesn't validate the number of datetimes that are provided. Per the specification, each interval should consist of exactly two datetime strings, so we should change the interval from:to: