Support all indexing variants

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.

[normanrz]

In this PR I ported over all indexing variants from the v2 codebase into v3. The Array class exposes the sames methods as in the v2 code base (e.g. get_basic_selection, set_orthogonal_selection, oindex[...]) whereas the AsyncArray only has _get_selection(indexer, ...) and _set_selection(indexer, ...).

The current status of this PR is: the tests are green but typing still causes some headaches.

There are a few breaking changes of the v3 code that we should discuss:

• 0-dimensional arrays (i.e. single values) are not supported
• selecting fields (object dtype) is shaky
• The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Please let me know your thoughts on these limitations @jhamman@d-v-b.

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
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Thanks for this effort! I will give it a closer look later today.

regarding these two concerns:

• 0-dimensional arrays (i.e. single values) are not supported

• selecting fields (object dtype) is shaky

I don't have a lot of experience with either of these features from v2, so I am probably not the best judge of how we want this to look. Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

The out kwarg for getitem doesn't work and can be complicated to implement with the new NDBuffer abstraction

Similarly, I never use out, but maybe @madsbk has some thoughts here?

[madsbk]

Regarding out, I think it should be all or nothing. That is, either we implement an output-by-caller policy where all components takes an output argument, or we don't use output arguments at all.

As @akshaysubr point out in #1751 (comment), it might be diffecult to support an output-by-caller policy so I am leaning to remove the out argument and make it clear that the Zarr stack will copy data in most cases.

[normanrz]

While I agree that providing an out kwarg is pointless if zarr-python is doing copies anyways, we have it in the existing API. I wonder if we should continue to provide the out arg but issue a (deprecation) warning?

[madsbk]

Good point, a deprecation warning is a good idea :)

[rabernat]

Are there any big time 0-dimensional array or object dtype users we can ping to have them look it over?

#1874 recently revealed that there are definitely users of 0-dimensional arrays. (Also python objects dtypes.)

[d-v-b]

we should look for a way to simplify this as much as we can.OrthogonalSelector vs OrthogonalSelection, where the latter contains the former, is a recipe for confusion.

[d-v-b]

I think when we use a type alias like BlockSelectionNormalized for tuple[BlockSelector,...] we lose some readability. To know that BlockSelectionNormalized is tuple[int | slice, ...] I have to do 2 lookups, and we aren't even saving lines of code because the type aliases are longer than the types. Was there a particular problem caused by the plain type annotations?

[d-v-b]

From the name OrthogonalSelectionNormalized I would expect that this type takes OrthogonalSelection, but it takes OrthogonalSelecTOR, which is a bit surprising / confusing

[normanrz]

I got the types to a state where mypy doesn't complain anymore. I know that the types are far from ideal. However, it will take more work to iron that out given the variety of indexing methods that zarr-python supports and I don't want to hold this off from the alpha release.

[d-v-b]

This is great, thanks @normanrz! Agreed that we can sort out the types in a later effort.

[jhamman]

Looking great @normanrz -- a few comments to help tidy this up.