Mutable datatypes can break observability
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- python
- Domain
- observability
Research direction
Start by locating the DataProperty implementation and the observability behavior around set. Compare the proposed handling for mutable dict, list, and custom-class types, including Mapping and Sequence annotations. Done requires a decided policy and corresponding validation or non-observable behavior, but the issue does not identify tests or settle which alternative to implement.
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe.
A DataProperty typed as a dict may have its value changed without triggering __set__. This leads to the property's value becoming out of sync with observers.
Describe the solution you'd like
DataProperty instances that are typed as a mutable object (e.g. dict, list, or a custom class) should either not be observable, or should raise an error when they are defined (or once the type is resolved).
For mapping or sequence types, I think it would be really nice to have the error message suggest typing them as Mapping or Sequence. Type checked code should then not allow mutation of these objects. We could even use a MappingProxy for dict values to ensure they don't get mutated, or convert list to tuple to achieve the same effect.
I think this merits a bit of discussion. Observability isn't something that's used much at the moment, but I can see it becoming important, for example in efficient client implementations. I would be keen to make sure that it works properly.
Describe alternatives you've considered
I've previously attempted to implement a deep reactive dictionary. This does not seem like a good idea: there are far too many things to go wrong.
- Dominant language
- Python
- Stars
- 9
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from labthings/labthings-fastapi
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
labthings/labthings-fastapi#405 ·
-
drop-python-version
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
labthings/labthings-fastapi#354 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
labthings/labthings-fastapi#312 · 1 comment ·
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 65/100
labthings/labthings-fastapi#407 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
labthings/labthings-fastapi#404 · 2 comments ·
All issues in labthings/labthings-fastapi
Similar issues
-
agent-ready documentation needs-triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
instance instance add
Difficulty 1/5 Under an hour Newbie friendliness 72/100
searxng/searx-instances#939 · 1 comment ·
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100