Skip to content

Return ndarrays from encode and (where possible) decode #136

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 5 commits into from
Nov 29, 2018
Merged

Return ndarrays from encode and (where possible) decode #136

merged 5 commits into from
Nov 29, 2018

Conversation

jakirkham
Copy link
Member

@jakirkham jakirkham commented Nov 29, 2018

Ensures binary encode functions return ndarrays generally. This makes the output easier to anticipate and work with. Also allows more unusual outputs like objects' internal buffers to be exposed in a friendly way to end users (while avoiding copying). Where possible also ensure decode functions return ndarrays.

TODO:

  • Unit tests and/or doctests in docstrings
  • tox -e py37 passes locally
  • tox -e py27 passes locally
  • Docstrings and API docs for any new/modified user-facing classes and functions
  • Changes documented in docs/release.rst
  • tox -e docs passes locally
  • AppVeyor and Travis CI passes
  • Test coverage to 100% (Coveralls passes)

Standardize the output of the `encode` function a bit by ensuring it
returns an `ndarray`. This is done without copying as it only takes a
view onto the data. Has the advantage of leveraging objects under the
hood that might not appear as nice like objects' internal buffers
without impacting the user or unnecessarily copying the data to `bytes`.
Also makes it a bit easier to work with the output as users can do
anything they would normally want to with `ndarray`s.
Where possible, ensure that `decode` returns an `ndarray`. Many codecs
already do this except for some unusual ones that work with Python
objects or text data. In the cases where the data is known to be binary,
try to return `ndarray`s. This makes it pretty easy for end users of
this data to do whatever they would like with it.
@jakirkham jakirkham requested a review from alimanfoo November 29, 2018 16:39
@jakirkham
Copy link
Member Author

Please let me know how you want this listed in the changelog (if at all).

Copy link
Member

@alimanfoo alimanfoo left a comment

Choose a reason for hiding this comment

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

Thanks @jakirkham, LGTM. Re changelog, I think it would be good to add something, how about something like:

* Return values from encode() and decode() methods are now returned as numpy arrays for consistency across codecs. By :user:`John Kirkham <jakirkham>`, :issue:`136`.

@alimanfoo
Copy link
Member

Went ahead and added release notes and resolved merge conflict, hope that's OK. Will merge if CI passes.

@jakirkham jakirkham added this to the 0.6.0 milestone Nov 29, 2018
@jakirkham
Copy link
Member Author

Great, thanks for doing that, @alimanfoo. SGTM

@alimanfoo alimanfoo merged commit fd46c4c into zarr-developers:master Nov 29, 2018
@jakirkham jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03
@jakirkham
Copy link
Member Author

Apologies for not opening a new issue for this. Happy to do so if needed.

Should we cut the release now or were there some other things still needed?

@alimanfoo
Copy link
Member

No problem at all. I think cut the release now: #137.

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.

2 participants