Add typing and docs for rbtools API transport and request.
Review Request #12653 — Created Sept. 29, 2022 and submitted
This change updates the bulk of the rest of the API layer in RBTools
with modern documentation and type hints.
- Ran unit tests.
- Posted some changes.
Summary | ID |
---|---|
2f57e4cb8e157693ba1a1665d1ac47c107acf35a |
Description | From | Last Updated |
---|---|---|
'typing.Callable' imported but unused Column: 1 Error code: F401 |
reviewbot | |
'http.client.UNAUTHORIZED' imported but unused Column: 1 Error code: F401 |
reviewbot | |
block comment should start with '# ' Column: 9 Error code: E265 |
reviewbot | |
line too long (82 > 79 characters) Column: 80 Error code: E501 |
reviewbot | |
'typing.Union' imported but unused Column: 1 Error code: F401 |
reviewbot | |
Could add a Deprecated: section to the doc. This applies to the other methods that are deprecated too. |
maubin | |
This warning shouldn't be here. |
maubin | |
This should say "Use CachedHTTPResponse.headers instead.". |
maubin | |
This should say "Use CachedHTTPResponse.code instead.". |
maubin | |
This warning shouldn't be here. |
maubin | |
Could add Args: and Returns: sections. |
maubin | |
Forgot to add typing here. |
maubin | |
Should we use some other variable names for type and format since these clash with Python's built in methods? Does … |
maubin | |
Can we :py:class: this? |
chipx86 | |
We can use :py:attr: here. |
chipx86 | |
We can use :py:attr: here. Same with others. |
chipx86 | |
Properties should go before non-constructor methods. Same below. |
chipx86 | |
One of the more confusing aspects of the new typing stuff is that it's hard to tell what's a class-level … |
chipx86 | |
Won't this always end up returning a RootResource or None? I think we should use Optional[RootResource] here. Same with the … |
chipx86 | |
I think we always guarantee a Resource or None from this method as a return type. |
chipx86 | |
Same as get_path. |
chipx86 | |
We don't actually have a return type for this in Transport or SyncTransport. Maybe we should? Do we want to? |
chipx86 | |
Same as login. |
chipx86 | |
Since we have typed parameters in here, let's use the one-param-per-line form to stay consistent with others like this. Same … |
chipx86 | |
This can probably just be: decoder = DECODER_MAP.get(format, DefaultDecoder) |
chipx86 | |
We should have one param per line here. |
chipx86 | |
tuple[...] will break on Python 3.7/3.8. This needs to use Tuple[...] for now. |
chipx86 | |
We re-define this Union a couple times. Let's make a TypeAlias. |
chipx86 | |
One parameter per line here. |
chipx86 | |
One parameter per line with types. |
chipx86 | |
The description can't be indented here. |
chipx86 | |
RBTools 5. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
Can we just super() here? |
chipx86 | |
I think we can safely use super() here. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
These start at 0. |
chipx86 | |
Can we document this while here? |
chipx86 | |
Seems like a reasonable bug fix, but one that slips through the cracks. While small, can we pull this out … |
chipx86 | |
Missing trailing comman and return type (-> None). |
chipx86 | |
Missing trailing comma. Same on functions below. |
chipx86 | |
Same notes as above with the return types here. We should always expect resources. Same below. |
chipx86 | |
These can easily fit one per line starting on the opening line. |
chipx86 | |
__name__ |
chipx86 | |
Missing trailing comma. |
chipx86 | |
We should document these, like our other TypedDicts. |
chipx86 | |
One parameter per line when typed. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
Missing a trailing comma. |
chipx86 | |
Can you add a Version Added? |
chipx86 |
- Commits:
-
Summary ID 3eae8188ab528607a7519411649a99ed3ed4a909 8f46dc053e8e3cbb70ae9ec1bd2f509a3b78802c
Checks run (2 succeeded)
- Commits:
-
Summary ID 8f46dc053e8e3cbb70ae9ec1bd2f509a3b78802c 350047dedb2e13794d7ccd336db8a33d6948f6a9
Checks run (2 succeeded)
-
-
-
-
-
-
One of the more confusing aspects of the new typing stuff is that it's hard to tell what's a class-level attribute and what's documentation for an instance-level attribute.
The pattern I've been doing is to put this before the blocks of instance attributes:
###################### # Instance variables # ######################
That way it's very clear where something is supposed to go as code changes, reducing the risks of mixing up class and instance variables.
-
Won't this always end up returning a
RootResource
orNone
? I think we should useOptional[RootResource]
here.Same with the
Returns:
-
-
-
We don't actually have a return type for this in
Transport
orSyncTransport
. Maybe we should? Do we want to? -
-
Since we have typed parameters in here, let's use the one-param-per-line form to stay consistent with others like this.
Same with others below.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Seems like a reasonable bug fix, but one that slips through the cracks. While small, can we pull this out so we can better track it and help with the release notes?
-
-
Maybe worth creating a base class we can refer to? Maybe not in this change, but it seems like we should have one.
-
-
-
-
-
-
-
- Commits:
-
Summary ID 350047dedb2e13794d7ccd336db8a33d6948f6a9 c56aff3436dd7aad7a303a2cafb07fbb0b77d0ea