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.
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: |
There was a problem hiding this comment.
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.
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?
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.
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.
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.
Okay, that's good enough for me!
codebasin/util.py
Outdated
| @@ -59,7 +55,7 @@ def ensure_ext(path: os.PathLike[str], extensions: Iterable[str]): | |||
| raise ValueError(f"{path} does not have a valid extension: f{exts}") | |||
There was a problem hiding this comment.
You didn't change this, but I think Copilot is right. There shouldn't be a second "f" here, right?
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.
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.
| 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`). |
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.
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. |
| dict[str, Any] | ||
| The loaded TOML object, represented as a Python | ||
| dict with str key/value mappings. |
There was a problem hiding this comment.
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.
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 <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
`tomllib.load` signature returns a dict; this change matches what is ultimately returned by `tomllib.load`. Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
Signed-off-by: Kin Long Kelvin Lee <kin.long.kelvin.lee@intel.com>
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