🐛 Make Entry dict access symmetric for ENTRYTYPE and ID#561
Merged
Conversation
`entry[ENTRYTYPE]` / `entry[ID]` returned `entry_type` / `key`, but the corresponding assignment created a literal field that was shadowed on read and serialized as a regular field (e.g. `ENTRYTYPE = book`) on write. Particularly dangerous for v1 migrators, where these dict keys were the documented way to change an entry type or key. `__setitem__` now mirrors `__getitem__` and sets `entry_type` / `key`; `__contains__` now reports the two keys as contained, consistent with `__getitem__` and `items()`. Fixes #532 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
Fixes #532
entry[ENTRYTYPE]/entry[ID]returnentry_type/key, but the corresponding assignment created a literalField(ENTRYTYPE, ...). The bogus field was shadowed by__getitem__on read (soe[ENTRYTYPE] = book; e[ENTRYTYPE]still returnedarticle) and serialized as a regularENTRYTYPE = bookline on write. Particularly dangerous for v1 migrators, where assigning these dict keys was the documented way to change an entry type or key.Changes
__setitem__mirrors__getitem__:ENTRYTYPEandIDsetentry_type/keyinstead of creating a field. Mirroring (rather than raising) was chosen because these dunders exist precisely for v1 compatibility, and mirroring restores the dict invariante[k] = v ⟹ e[k] == vwith exactly the v1 semantics.__contains__had the same asymmetry (ENTRYTYPE in entrywasFalsealthoughentry[ENTRYTYPE]succeeds anditems()lists it); it now returnsTruefor the two magic keys.get()/pop()(they returnFieldobjects, and there is no sensibleFieldfor the entry type) and__delitem__(deleting the entry type is nonsensical; it keeps harmlessly no-op-ing).A literal field named
ENTRYTYPE/IDcan still be created viaset_field()/fieldsif anyone genuinely needs that; only the dict-mimicking shorthand routes to the properties.🤖 Generated with Claude Code