Skip to content

Update dtype usage in zarr/meta.py #700

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

Merged
merged 2 commits into from
Feb 17, 2021

Conversation

joshmoore
Copy link
Member

@joshmoore joshmoore commented Feb 15, 2021

Changes in zarr's annotations, numpy, and/or mypy have led to failures on mypy zarr/across a large number of PRs. This tries to take the most direct route to passing GitHub actions so that PRs can be unblocked.

Thanks to @rgommers and @seberg for jumping in.

TODO:

  • Add unit tests and/or doctests in docstrings
  • Add docstrings and API docs for any new/modified user-facing classes and functions
  • New/modified features documented in docs/tutorial.rst
  • Changes documented in docs/release.rst
  • AppVeyor and Travis CI passes
  • Test coverage is 100% (Coveralls passes)

Changes in numpy have led to failures on `mypy zarr/`
across a large number of PRs.
@joshmoore
Copy link
Member Author

Failures can be seen in https://github.com/zarr-developers/zarr-python/pull/699/checks?check_run_id=1904975788

arr/meta.py:82: error: Incompatible return value type (got "List[Union[Tuple[str, str], Tuple[str, str, Tuple[int, ...]]]]", expected "str")
zarr/meta.py:183: error: "generic" has no attribute "real"
zarr/meta.py:184: error: "generic" has no attribute "imag"
Found 3 errors in 1 file (checked 30 source files)

@rgommers
Copy link

Hmm, the dtype.descr change surprises me. Good chance it's on purpose, but I don't really want to comb through multiple NEPs - so let's just ask @seberg.

@seberg
Copy link

seberg commented Feb 15, 2021

Do you know what changed? This has nothing to do with the dtype NEPs, but np.dtype(...).descr has never returned a string as far as I can tell. The only actual change I can think of (and find!) is that we might be returning unicode strings instead of bytes somewhere around here.

@joshmoore
Copy link
Member Author

joshmoore commented Feb 15, 2021

Thanks, both. I was assuming it was a numpy bump that led to this, but I'll need to try to find what the change was, unless @Carreau knows.

Another possibility is that mypy has gotten stricter, in which case I could update the annotation rather than the logic.

@seberg
Copy link

seberg commented Feb 15, 2021

I would guess the typing is due to NumPy 1.20 now including typing. The .descr change I am confused about though, since I am not aware of a change.

@codecov
Copy link

codecov bot commented Feb 15, 2021

Codecov Report

Merging #700 (79733be) into master (b0b161b) will increase coverage by 0.48%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #700      +/-   ##
==========================================
+ Coverage   99.45%   99.94%   +0.48%     
==========================================
  Files          28       28              
  Lines       10262    10263       +1     
==========================================
+ Hits        10206    10257      +51     
+ Misses         56        6      -50     
Impacted Files Coverage Δ
zarr/meta.py 100.00% <100.00%> (ø)
zarr/util.py 100.00% <0.00%> (+15.06%) ⬆️

@joshmoore
Copy link
Member Author

Asked for vetoes in gitter. Since all PRs are currently failing, I'm going to merge and start re-running the builds. If there are any issues with the changes here, I'll be happy to open a follow-up PR.

@joshmoore joshmoore merged commit 23422fc into zarr-developers:master Feb 17, 2021
@joshmoore joshmoore deleted the fix-mypy branch February 17, 2021 20:11
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.

3 participants