Skip to content
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

Add strict support for mypy #169

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

muddyfish
Copy link
Contributor

@muddyfish muddyfish commented Mar 6, 2024

Description

Adds strict type checking with mypy. From the mypy guide, it says

If you run mypy with the --strict flag, you will basically never get a type related error at runtime without a corresponding mypy error, unless you explicitly circumvent mypy somehow.

I think this would be an ideal situation to be in, if possible. It does add extra work however when writing the code to ensure it type checks completely.

S3MapDataset and S3IterableDataset are now implemented as generics. This has no impact for customers not using type checking, but should improve IDE & mypy support.

Additional context

Changes the constructor for S3MapDataset and S3IterableDataset. These constructors are not public, so it's OK to change.

  • I have updated the CHANGELOG or README if appropriate

Related items

Testing

mypy --strict s3torchconnector/src && mypy --strict s3torchconnectorclient/python/src passes


By submitting this pull request, I confirm that my contribution is made under the terms of BSD 3-Clause License and I agree to the terms of the LICENSE.

Copy link
Contributor

@dnanuti dnanuti left a comment

Choose a reason for hiding this comment

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

I am not sure about these changes, they make the code harder to read and duplicate the constructor methods due to @overload. What's the benefit for this?

@@ -17,8 +28,10 @@

log = logging.getLogger(__name__)

T_co = TypeVar("T_co", covariant=True)
Copy link
Contributor

Choose a reason for hiding this comment

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

):
) -> S3IterableDataset[S3Reader]: ...

@overload
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to introduce this overload just for typing?


from s3torchconnectorclient._mountpoint_s3_client import ObjectInfo, GetObjectStream


class S3Reader(io.BufferedIOBase):
class S3Reader(io.BufferedIOBase, IO[bytes]):
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we extending also IO[bytes]?

@@ -187,3 +188,12 @@ def writable(self) -> bool:
bool: Return whether object was opened for writing.
"""
return False

def write(self, data: Any) -> int:
Copy link
Contributor

Choose a reason for hiding this comment

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

Similarly to these, shouldn't the writer throw on READ?

Also, I'd rather say "Not supported" as I don't think we'll implement write for S3Reader.

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