Return `ndarray`s from `encode` and (where possible) `decode` by jakirkham · Pull Request #136 · zarr-developers/numcodecs

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham · 2018-11-29T15:58:48Z

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 · 2018-11-29T16:41:03Z

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

alimanfoo

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 · 2018-11-29T18:24:37Z

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

jakirkham · 2018-11-29T19:16:38Z

Great, thanks for doing that, @alimanfoo. SGTM

jakirkham · 2018-11-29T22:05:51Z

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 · 2018-11-29T22:07:37Z

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

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

jakirkham added 3 commits November 29, 2018 11:14

Regenerate C files from Cython files
90505c9

jakirkham requested a review from alimanfoo November 29, 2018 16:39

alimanfoo approved these changes Nov 29, 2018
View reviewed changes

alimanfoo added 2 commits November 29, 2018 18:22

release notes [ci skip]
97c6b18

Merge branch 'master' into ret_ndarray_encode_decode
2012553

jakirkham added this to the 0.6.0 milestone Nov 29, 2018

alimanfoo merged commit fd46c4c into zarr-developers:masterNov 29, 2018

jakirkham deleted the ret_ndarray_encode_decode branch November 29, 2018 22:03

This was referenced Nov 30, 2018
Ensure VLen*encode methods return ndarrays #144
Merged
Ensure Pickleencode method return ndarrays #147
Closed

alimanfoo mentioned this pull request Dec 3, 2018
Comparison of non-trivial, uncompressed, in-memory Zarr Arrays fails zarr-developers/zarr-python#348
Closed

jakirkham mentioned this pull request Dec 3, 2018
Revert ndarray coercion of encode returned data #155
Merged
8 tasks

Uh oh!

Conversation

jakirkham commented Nov 29, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

alimanfoo left a comment

Choose a reason for hiding this comment

Uh oh!

alimanfoo commented Nov 29, 2018

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

alimanfoo commented Nov 29, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakirkham commented Nov 29, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

alimanfoo left a comment

Choose a reason for hiding this comment

Uh oh!

alimanfoo commented Nov 29, 2018

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

alimanfoo commented Nov 29, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakirkham commented Nov 29, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

alimanfoo left a comment

Choose a reason for hiding this comment

Uh oh!

alimanfoo commented Nov 29, 2018

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

jakirkham commented Nov 29, 2018

Uh oh!

alimanfoo commented Nov 29, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakirkham commented Nov 29, 2018•
edited
Loading

jakirkham commented Nov 29, 2018•
edited
Loading

jakirkham commented Nov 29, 2018•
edited
Loading

jakirkham commented Nov 29, 2018•
edited
Loading

jakirkham commented Nov 29, 2018•
edited
Loading