Skip to content
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

Dtype str in desc #438

Merged
merged 21 commits into from
Jul 11, 2024
Merged

Dtype str in desc #438

merged 21 commits into from
Jul 11, 2024

Conversation

jwlodek
Copy link
Member

@jwlodek jwlodek commented Jul 8, 2024

Solves #257. Currently a work in progress - the tests don't yet pass. Making a draft PR to track progress.

@jwlodek jwlodek marked this pull request as ready for review July 8, 2024 20:34
@jwlodek
Copy link
Member Author

jwlodek commented Jul 8, 2024

@coretl @genematx @mrakitin @danielballan

First pass at this is done, and should be ready for review. All tests are passing now.

@jwlodek
Copy link
Member Author

jwlodek commented Jul 8, 2024

The linter error appears to be related to ruff reformatting a file, but I cannot reproduce in my dev environment. Is there something I'm missing? Running ruff --fix and ruff check src tests. Both give All checks passed!

@coretl
Copy link
Collaborator

coretl commented Jul 9, 2024

Lint runs on the result of the branch merged to main, so maybe that made some linting error?

Please can you update pyproject.toml to match this line:
https://github.com/DiamondLightSource/python-copier-template/blob/516ffaa89832a71a2dedf9446a3d284b9011e27b/pyproject.toml#L52
Then you can at least see what it would change!

Copy link
Collaborator

@coretl coretl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it's almost there thanks! A few minor points

tests/epics/test_signals.py Outdated Show resolved Hide resolved
@@ -71,6 +71,7 @@ async def _describe(self) -> Dict[str, DataKey]:
source=self.panda_device.data.hdf_directory.source,
shape=ds.shape,
dtype="array" if ds.shape != [1] else "number",
dtype_str="<f8", # PandA data should always be written as Float64
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be true after PandABlocks/PandABlocks-client#87

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coretl, are you OK with keeping this change merge the PR?

src/ophyd_async/epics/_backend/_aioca.py Outdated Show resolved Hide resolved
src/ophyd_async/core/soft_signal_backend.py Outdated Show resolved Hide resolved
src/ophyd_async/epics/areadetector/writers/nd_plugin.py Outdated Show resolved Hide resolved
Copy link
Member

@mrakitin mrakitin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks good to me.

Copy link
Contributor

@genematx genematx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. Thanks, Jakub! I have one potential refactoring comment, but likely it's just may lack of understanding of internals of ophyd-async.
Aside, are we going to add chunks field as well? I think it should go into a separate PR, but we will need them in Tiled eventually.

dtype_numpy = ""
if isinstance(value, list):
if len(value) > 0:
dtype_numpy = np.dtype(type(value)).descr[0][1]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand how this works. Should it be np.dtype(value[0].dtype) on line 81 (or something along those lines). Also, is value always either a scalar or a list? Would it be safer to check if it's an iterable instead?
Or is it a numpy array or a list?
Maybe adding a typehint to value in the function signature could be helpful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good points, @genematx! I overlooked that case during my review.
Maybe it should just be np.dtype(type(value[0])) as the value[0] will be a number, which won't (or may not?) have .dtype method.

To compare two approaches:

In [28]: np.dtype(type([1, 2, 3][0])).descr
Out[28]: [('', '<i8')]

In [29]: np.dtype(type([1, 2, 3])).descr
Out[29]: [('', '|O')]

I support adding a type annotation to the signature and a docstring to explain the expected input types.

@coretl coretl merged commit 0f67e37 into bluesky:main Jul 11, 2024
11 checks passed
@jwlodek jwlodek deleted the dtype-str-in-desc branch August 9, 2024 17:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants