ittuann opened a new pull request, #2884:
URL: https://github.com/apache/streampipes/pull/2884
<!--
~ Licensed to the Apache Software Foundation (ASF) under one or more
~ contributor license agreements. See the NOTICE file distributed with
~ this work for additional information regarding copyright ownership.
~ The ASF licenses this file to You under the Apache License, Version 2.0
~ (the "License"); you may not use this file except in compliance with
~ the License. You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS,
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~ See the License for the specific language governing permissions and
~ limitations under the License.
~
-->
<!--
Thanks for contributing! Here are some tips you can follow to help us
incorporate your contribution quickly and easily:
1. If this is your first time, please read our contributor guidelines:
- https://streampipes.apache.org/getinvolved.html
- https://cwiki.apache.org/confluence/display/STREAMPIPES/Getting+Started
2. Make sure the PR title is formatted like: `[#<GitHub issue id>] PR title
...`
3. If the PR is unfinished, add '[WIP]' in your PR title, e.g.,
`[WIP][#<GitHub issue id>] PR title ...`.
4. Please write your PR title to summarize what this PR proposes/fixes.
5. Link the PR to the corresponding GitHub issue (if present) in the
`Development` section in the right menu bar.
6. Be sure to keep the PR description updated to reflect all changes.
7. If possible, provide a concise example to reproduce the issue for a
faster review.
8. Make sure tests pass via `mvn clean install`.
9. (Optional) If the contribution is large, please file an Apache ICLA
- http://apache.org/licenses/icla.pdf
-->
### Purpose
<!--
Please clarify what changes you are proposing and describe how those changes
will address the issue.
Furthermore, describe potential consequences the changes might have.
-->
```
mypy.....................................................................Failed
- hook id: mypy
- duration: 5.81s
- exit code: 1
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
tests\client\test_versions.py:47: error: "Resource" has no attribute
"backend_version" [attr-defined]
self.assertEqual("development", result.backend_version)
^~~~~~~~~~~~~~~~~~~~~~
Found 1 error in 1 file (checked 5 source files)
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 5 source files
Success: no issues found in 4 source files
```
I analyzed that the issue is due to the `VersionEndpoint` class inheriting
from `APIEndpoint` and calling the parent `APIEndpoint` class's `get()` method
through `super()` in its `get()` method. Inside the parent `APIEndpoint`
class's `get()` method, `response = self._make_request(...)` is used, where the
`_make_request()` method returns an instance of the `Response` class. This is
what caused mypy to throw an error during static analysis.
However, in actual execution, the object type returned by the `get()` method
depends on the class defined by the `_resource_cls()` method implemented by
each endpoint (for example, `VersionEndpoint` returns an instance of the
`Version` class through `Versions._container_cls`).
Following this, I have updated the relevant code to ensure type consistency,
resolving the error found during mypy static analysis.
### Remarks
<!--
Is there anything left we need to pay attention on?
Are there some references that might be important? E.g. links to Confluence,
or discussions
on the mailing list or GitHub.
-->
PR introduces (a) breaking change(s): <yes/no>
no
PR introduces (a) deprecation(s): <yes/no>
no
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]