-
Notifications
You must be signed in to change notification settings - Fork 3
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 to create a AfidSet class #14
Conversation
An `afids.py` file has been added in order to create an AFIDSet dict class, enabling the storing of both metadata information, well as loading fiducials from files directly into a dataframe. The choice of using a dataframe here is for easier downstream manipulation. - `get_afid` has been moved into here as a method of the AfidSet class Moved extension specific file handling into its own `.py` files (e.g. `extensions/fcsv.py`). This choice was made to simplify the maintenance of handling different file extensions. - Separate semi-private methods are used for grabbing the metadata, as well as loading the fiducials into a polars dataframe. Additionally `io.py` has been refactored to generalize the handling of different file types (calling the methods within the different `extensions`). Updates poetry.lock and pyproject.toml to include the `attrs` library
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #14 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 6 8 +2
Lines 150 348 +198
==========================================
+ Hits 150 348 +198
|
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.
This is looking good, just a few requests/questions
afids_utils/afids.py
Outdated
|
||
slicer_version: str = attr.field() | ||
coord_system: str = attr.field() | ||
afids_df: pl.DataFrame = attr.field() |
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.
I think my preferred approach would be to define an Afid
class with a label and x, y, z coords, then make this a list[Afid]
, and add a validator that it contains 32 Afid
s with labels in order.
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.
Yes, we can certainly do that - it'd be similar to how we had it implemented in the validator. The validation logic is implemented, just not as a separate method (under load
) currently. If we do switch to doing it that way, than I would say lets just get rid of the use of dataframes all together - I don't see foresee any use case for them and would save us an additional dependency.
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.
Sounds good on all counts, with the note that I think it makes sense to implement the validation logic as an attrs validator to check the validation regardless of where the AFIDs are coming from
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.
That works for me, with the validation logic currently in place, lets move the attrs validator as a thing to do during the sprint. Should be easy enough to take what is currently there.
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.
Cool, this has been done now with the latest commit sans attrs validator.
- Remove `io.py`, moving methods to the AfidSet class. `load` is now a ClassMethod while `save` is a method of the instance. - Added an `AfidPosition` class, which is now used to store AFIDs - Drops polars from use, favouring `List[AfidPosition]` instead - Update mismatched desc in template.fcsv - Update strategies.py to generate coords using `AfidPosition` - Update all tests to correspond with changes made
754cbaa
to
c3fa441
Compare
I think at this point, minus some of the additional stuff we talked about and barring any major changes - we should try to get this pushed in as the base code to build off of for the sprint. |
Proposed changes
First pass refactor to include an AfidSet class in-time for the mini sprint. There are still a few things to iron out, but I think this should provide the basic model and some examples of needed methods (for json handling). The test cases at the moment are very basic (e.g. loading the existing valid fcsv file), but would like to include a mock AfidSet to use in tests in the future.
Types of changes
What types of changes does your code introduce? Put an
x
in the boxes that applyChecklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you are unsure about any of the choices, don't hesitate to ask!poe quality
taskNotes
All PRs will undergo the unit testing before being reviewed. You may be requested to explain or make additional changes before the PR is accepted.