-
-
Notifications
You must be signed in to change notification settings - Fork 19
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 a TimeConfigBuilder to avoid further breaking changes #46
Conversation
I noticed while updating pydantic-core that despite efforts to avoid breaking changes adding a field to TimeConfig is indeed a breaking change. I'm adding this TimeConfigBuilder so that we can add more options down the road withou a breaking change.
please review |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #46 +/- ##
==========================================
+ Coverage 99.07% 99.10% +0.02%
==========================================
Files 6 6
Lines 862 890 +28
==========================================
+ Hits 854 882 +28
Misses 8 8
Continue to review full report in Codecov by Sentry.
|
I'm a bit confused by why this is necessary and what it does. I thought you could just do TimeConfig { unix_timestamp_offset: Some(123), ..Default::default() }; And extra settings added to |
Yes but then you have to force users to do that, and it’s not immediately obvious, eg in pydantic-core that’s not what we did. The builder pattern is meant precisely to address this situation. |
No real performance impact:
|
I noticed while updating pydantic-core that despite efforts to avoid breaking changes adding a field to TimeConfig is indeed a breaking change. I'm adding this TimeConfigBuilder so that we can add more options down the road without a breaking change.
@samuelcolvin I realize we probably think we won't need to add any more options, if you're 100% sure of this please just close this, but I figured since we had 0 a week ago and now have 2...