-
Notifications
You must be signed in to change notification settings - Fork 75
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
Use msgspec.UNSET
for tracking unset fields
#350
Merged
Merged
Conversation
This file contains 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
This makes the internal `NODEFAULT` singleton public, and switches the all previous usage of `msgspec.UNSET` to use `msgspec.NODEFAULT` instead. This is a *breaking change*. In the unlikely case a user was using `msgspec.UNSET` directly (it's a fairly fringe API to use), they should move to using `msgspec.NODEFAULT` instead. This breaking change is needed so we can reclaim the `msgspec.UNSET` singleton for an alternate purpose.
This adds support for encoding object-like types (Struct, dataclasses, attrs) where some fields may contain the `msgspec.UNSET` singleton. In this case, these fields are omitted from the encoded message. Encoding `msgspec.UNSET` in locations other than a direct object field (e.g. in `[1, 2, msgspec.UNSET]`) will result in a type error.
This makes UNSET's semantics the same as `None`, except it's a different singleton.
SyntaxColoring
approved these changes
Mar 23, 2023
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.
Docs make sense to me! Thanks. A couple of suggestions.
This lets type checkers do a better job of type narrowing. For ease of implementation we only make this change in the type stubs. In normal usage the singleton object and types should be treated as opaque objects by users, lieing in the type stubs here seems unlikely to cause an issue.
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
msgspec.UNSET
is a singleton object used to indicate that a field has no set value. This is useful for cases where you need to differentiate between a message where a field is missing and a message where the field is explicitlyNone
.During encoding, any field containing
UNSET
is omitted from the message.During decoding, if a field isn't explicitly set in the message, the default value of
UNSET
will be set instead. This lets downstream consumers determine whether a field was left unset, or explicitly set toNone
UNSET
fields are supported formsgspec.Struct
,dataclasses
, andattrs
types. It is an error to usemsgspec.UNSET
ormsgspec.UnsetType
anywhere other than a field for one of these types.For ease of use,
UNSET
is falsey and a singleton - usage in predicates should be fairly similar to how Python users already check forNone
:Note that this repurposes the existing
msgspec.UNSET
singleton, and is thus a breaking change. Anyone who was previously making use ofmsgspec.UNSET
should move to usingmsgspec.NODEFAULT
instead. My hope is this breakage affects no users, as the previousmsgspec.UNSET
was fairly new, and was a pretty internal API.Fixes #344.