-
Couldn't load subscription status.
- Fork 10
util.py module type hints
#192
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
Conversation
5b26279 to
12e23ad
Compare
|
My last commit has the DCO sign-off - not sure why it's not passing? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds type hints and updates docstrings in the util.py module for improved code clarity and consistency. Key changes include updating the copyright year, adding type annotations for safe_open_write_binary and valid_path, and refining the _load_toml return type and documentation.
Comments suppressed due to low confidence (1)
codebasin/util.py:55
- The extra 'f' in the formatted string appears to be a mistake. It should be removed so that the error message is formatted using the variable 'exts' correctly.
raise ValueError(f"{path} does not have a valid extension: f{exts}")
codebasin/util.py
Outdated
|
|
||
|
|
||
| def safe_open_write_binary(fname): | ||
| def safe_open_write_binary(fname: os.PathLike[str]) -> TextIOWrapper: |
Copilot
AI
May 9, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The return type annotation 'TextIOWrapper' is inconsistent with opening a file in binary write mode. Consider changing it to a type such as 'BinaryIO' or another appropriate binary stream type.
| def safe_open_write_binary(fname: os.PathLike[str]) -> TextIOWrapper: | |
| def safe_open_write_binary(fname: os.PathLike[str]) -> typing.BinaryIO: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know enough about the differences here. Could you try making the change and see if the type-hinting tools are still satisfied?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LSP seems happy with change made in 8e293ed
Because we don't squash on merge, all commits in the PR need the DCO sign-off. I think the only way to add the missing sign-off retroactively is to do an interactive rebase, add the missing sign-offs, then force push. |
|
|
||
|
|
||
| def ensure_ext(path: os.PathLike[str], extensions: Iterable[str]): | ||
| def ensure_ext(path: os.PathLike[str], extensions: Iterable[str]) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not opposed to this, but I'm curious. Do conventions say to specify -> None in the case of no return types? I'm not sure which style guides to look at here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought there was that Python functions always return None, even if they don't have a return statement. For the developer it seems to be better to be explicit, since then you remove the ambiguity of "did we leave out the return signature, or does it really return None"?
Seems like mypy recommends this as well, even if we don't use mypy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that's good enough for me!
codebasin/util.py
Outdated
| extension = "".join(path.suffixes) | ||
| if extension not in extensions: | ||
| exts = ", ".join([f"'{ext}'" for ext in extensions]) | ||
| raise ValueError(f"{path} does not have a valid extension: f{exts}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You didn't change this, but I think Copilot is right. There shouldn't be a second "f" here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patched in 55af105
codebasin/util.py
Outdated
|
|
||
|
|
||
| def safe_open_write_binary(fname): | ||
| def safe_open_write_binary(fname: os.PathLike[str]) -> TextIOWrapper: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know enough about the differences here. Could you try making the change and see if the type-hinting tools are still satisfied?
codebasin/util.py
Outdated
| This function ensures that the file path does not contain | ||
| potentially dangerous characters such as null bytes (`\x00`) | ||
| or carriage returns/line feeds (`\n`, `\r`). These characters | ||
| can pose security risks, particularly in file handling operations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| This function ensures that the file path does not contain | |
| potentially dangerous characters such as null bytes (`\x00`) | |
| or carriage returns/line feeds (`\n`, `\r`). These characters | |
| can pose security risks, particularly in file handling operations. | |
| This function ensures that the file path does not contain | |
| potentially dangerous characters such as null bytes (`\x00`) | |
| or carriage returns/line feeds (`\n`, `\r`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed in c7ef2eb
codebasin/util.py
Outdated
| Notes | ||
| ----- | ||
| - This function is useful for validating file paths before performing | ||
| file I/O operations to prevent security vulnerabilities. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove this.
| Notes | |
| ----- | |
| - This function is useful for validating file paths before performing | |
| file I/O operations to prevent security vulnerabilities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed in c7ef2eb
| dict[str, Any] | ||
| The loaded TOML object, represented as a Python | ||
| dict with str key/value mappings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't thought about this before, so want to double-check you agree.
I think this was set up as -> object before because when we were loading JSON, the result was not guaranteed to be a dict. For example, a compilation database is an array of objects.
It does seem like TOML must be key-value pairs, and the documentation says that "TOML is designed to map unambiguously to a hash table". So I think this is right...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's why I left the JSON signature as object, but updated it for the TOML. tomllib.load's signature only returns dict[str, Any], because I think by design it can't return anything else (i.e. keys have to be strings).
|
Thanks, @laserkelvin. All of these changes look good to me, assuming you fix the DCO sign-off. I'm not going to formally approve it yet, because I don't want to accidentally merge it before the next release. |
Function does not actually return `bool` Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
`tomllib.load` signature returns a dict; this change matches what is ultimately returned by `tomllib.load`. Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
Signed-off-by: Kin Long Kelvin Lee <[email protected]>
c7ef2eb to
dca4807
Compare
Related issues
Closes #191, which is part of epic #182.
Proposed changes
This PR makes (currently) purely aesthetic changes by adding type hints to function signatures contained in
util.py, as well as updating docstrings to match implementations.safe_open_write_binary,valid_pathensure_ext,_load_toml