-
Notifications
You must be signed in to change notification settings - Fork 9
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
refactor: different pattern for structured annotations list and shapes union #237
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #237 +/- ##
==========================================
+ Coverage 86.33% 86.75% +0.41%
==========================================
Files 26 24 -2
Lines 1259 1200 -59
==========================================
- Hits 1087 1041 -46
+ Misses 172 159 -13 ☔ View full report in Codecov by Sentry. |
CodSpeed Performance ReportMerging #237 will improve performances by 25.59%Comparing Summary
Benchmarks breakdown
|
…ambert03/ome-types into better-structured-annotations
This reverts commit 3344920.
Wow! That looks like it was painful, @tlambert03. Thank you! I'm not sure I will be able to test before disappearing for the holidays, but it's definitely on my list. |
This PR improves the implementation of StructuredAnnotations and ShapeUnion.
These have been difficult objects to capture in a way that feels natural in a python context, while remaining true to the semantics of the original OME schema.
In ome-types v0.4, these objects both became list-like objects that removed the individual sub-fields. That is, they looked a bit more like this:
than this:
However, that came a bit at the expense of "correctness", and it also made the casting to JSON schema a bit clunky as well (which was recently fixed in a somewhat hacky way in #235).
This PR moves back towards the second pattern: a type
StructuredAnnotations
that does indeed have individual fields, matching the original XSD more faithfully... but it adds methods to that object that implement most (but not all) of the MutableSequence interface. That is, you can still useappend
,extend
,remove
,__getitem__
(but not__setitem__
) on the object itself.It's a significant internal refactor, but hopefully shouldn't break any external use cases (and the third-party tests for aicsimageio, omero-cli-transfer, and paquo are all still working after this PR).