Bring back "zarr" into repr

[alimanfoo]

In a mixed context it's not clear that a zarr array is from zarr, put "zarr" back into array and group reprs somehow.

[alimanfoo]

Also suggest removing the compression information (nbytes_stored, number of chunks initialized) as these can take some time to retrieve. Suggest moving these to a method or property, e.g., storage_info or something like that.

[jakirkham]

Yeah, it would also be nice if repr returned something that was relatively static between runs.

[alimanfoo]

How do you mean exactly? Eg, avoiding dict ordering randomness? And/or something else?

On Mon, 6 Mar 2017 at 20:11, jakirkham ***@***.***> wrote: Yeah, it would also be nice if repr returned something that was relatively static between runs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/alimanfoo/zarr/issues/83#issuecomment-284517215>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq8QjAUyIy_roiwklI01irH_RBHEABAks5rjGhvgaJpZM4KXFyK> .

-- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Email: [email protected] Web: http://purl.org/net/aliman Twitter: https://twitter.com/alimanfoo Tel: +44 (0)1865 287721

[jakirkham]

I suppose that would be included too. So using an OrderedDict would help.

Though was more referring to details like the compression information that seem to vary slightly even on the same data. Things like name, shape, dtype, and chunk shape should be fine.

[alimanfoo]

Yes the compression information has been a bit of a bane, small changes can make the doctests on docstring examples and the tutorial fail, which is a pain to keep up to date. In the numcodecs PR I ended up putting a load of ellipses in to try and reduce maintenance overhead. It would be nice to simplify the repr. It has been useful for me to see compression info easily to hand, but maybe we could think of an alternate way to access that information that is almost as convenient as repr.

…

On Tuesday, March 7, 2017, jakirkham ***@***.***> wrote: I suppose that would be included too. So using an OrderedDict would help. Though was more referring to details like the compression information that seem to vary slightly even on the same data. Things like name, shape, dtype, and chunk shape should be fine. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/alimanfoo/zarr/issues/83#issuecomment-284592509>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq8Qql719xO5zoUXyqa07z6r3Ji9U7Lks5rjLQIgaJpZM4KXFyK> .

-- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Email: [email protected] Web: http://purl.org/net/aliman Twitter: https://twitter.com/alimanfoo Tel: +44 (0)1865 287721

[jakirkham]

Was also thinking of doctests when thinking about repr. Totally agree with having a different method provide this.

As a side note, the dictionary changes in Python 3.6 are well explained in this message.