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? |  | |
| We can use :py:attr: here. |  | |
| We can use :py:attr: here. Same with others. |  | |
| Properties should go before non-constructor methods. Same below. |  | |
| One of the more confusing aspects of the new typing stuff is that it's hard to tell what's a class-level … |  | |
| Won't this always end up returning a RootResource or None? I think we should use Optional[RootResource] here. Same with the … |  | |
| I think we always guarantee a Resource or None from this method as a return type. |  | |
| Same as get_path. |  | |
| We don't actually have a return type for this in Transport or SyncTransport. Maybe we should? Do we want to? |  | |
| Same as login. |  | |
| Since we have typed parameters in here, let's use the one-param-per-line form to stay consistent with others like this. Same … |  | |
| This can probably just be: decoder = DECODER_MAP.get(format, DefaultDecoder) |  | |
| We should have one param per line here. |  | |
| tuple[...] will break on Python 3.7/3.8. This needs to use Tuple[...] for now. |  | |
| We re-define this Union a couple times. Let's make a TypeAlias. |  | |
| One parameter per line here. |  | |
| One parameter per line with types. |  | |
| The description can't be indented here. |  | |
| RBTools 5. |  | |
| Missing a trailing comma. |  | |
| Can we just super() here? |  | |
| I think we can safely use super() here. |  | |
| Missing a trailing comma. |  | |
| These start at 0. |  | |
| Can we document this while here? |  | |
| Seems like a reasonable bug fix, but one that slips through the cracks. While small, can we pull this out … |  | |
| Missing trailing comman and return type (-> None). |  | |
| Missing trailing comma. Same on functions below. |  | |
| Same notes as above with the return types here. We should always expect resources. Same below. |  | |
| These can easily fit one per line starting on the opening line. |  | |
| __name__ |  | |
| Missing trailing comma. |  | |
| We should document these, like our other TypedDicts. |  | |
| One parameter per line when typed. |  | |
| Missing a trailing comma. |  | |
| Missing a trailing comma. |  | |
| Missing a trailing comma. |  | |
| Missing a trailing comma. |  | |
| Missing a trailing comma. |  | |
| Can you add a Version Added? |  | 
- 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 RootResourceorNone? I think we should useOptional[RootResource]here.Same with the Returns:
- 
 
 
- 
 
 
- 
 We don't actually have a return type for this in TransportorSyncTransport. 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 
