Check tests folder with mypy

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅

[TomAugspurger]

Should we lint (some of?) or tests folder with mypy? This revealed some discrepancies between our type annotations and our usage in the tests, so I think it'd be good to include them. For example, some of the tests used something like

Array.create(shape=100`, ...)

as a shorthand for

Array.create(shape=(100,), ...)

But the type for shape was just ChunkCoords, which is tuple[int, ...]. If we want to allow this, then I think it's probably best to update the types to make that clear.

That said, there's a bunch of errors (399 remaining in tests/v3, 2009 in tests. Some of these are correct but annoying, like all the assert isinstance(arr, Array) in this PR, which was needed to convince mypy that zarr.open() had returned an Array and not a Group.

I'd propose adding tests/v3 to the list of checked files.

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)

[dstansby]

I think this is a great idea 👍 Is it worth reviewing this PR now, or are you intending to expand it to some other test files first?

[TomAugspurger]

I think the rough plan should be

1. Wait for [v3] h5py compat methods on Group #2128 before merging his.
2. Make the updates in several batches (expanding the number of files checked, and making whatever changes to the type annotations / code is necessary to support the API)

I think doing it all in one shot would be a mistake, since we are having to make some "runtime" changes to match the usage. And we might decide that some of the usage in the tests folder isn't desirable.

[jhamman]

Wait for #2128 before merging his.

✅