Skip to content
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

Pylance errors for catch_response and name parameters in self.client.get() #2563

Open
2 tasks done
jasonwashburn opened this issue Jan 24, 2024 · 6 comments · May be fixed by #2699
Open
2 tasks done

Pylance errors for catch_response and name parameters in self.client.get() #2563

jasonwashburn opened this issue Jan 24, 2024 · 6 comments · May be fixed by #2699
Labels
bug stale Issue had no activity. Might still be worth fixing, but dont expect someone else to fix it

Comments

@jasonwashburn
Copy link

Prerequisites

Description

When using 'catch_response' and 'name' paramters in 'self.client.get()', Pylance reports 'No parameter named...' for each. However, the code does function properly as documented/expected. It's possible that this could be an issue with Pylance itself as well.

image

Command line

locust -f pylance_bug.py

Locustfile contents

"""Simple test case for Pylance error."""
from locust import HttpUser, task


class MyUser(HttpUser):
    """Simple test case for Pylance error."""

    @task
    def index(self) -> None:
        """Simple test case for Pylance error."""
        with self.client.get(url="/", catch_response=True, name="testcase") as response:
            if response.text != "Success":
                response.failure("Got wrong response")

Python version

3.11.5

Locust version

2.20.1

Operating system

Red Hat Enterprise Linux 8.9

@cyberw
Copy link
Collaborator

cyberw commented Jan 24, 2024

Yea… it sucks, but it is really hard to fix (without wrapping every method). IIRC FastHttpUser is better, if that is any help.

@jasonwashburn
Copy link
Author

Yea… it sucks, but it is really hard to fix. IIRC FastHttpUser is better, if that is any help.

Any ideas or starting points on the cause? I'm willing to take a crack at it.

@cyberw
Copy link
Collaborator

cyberw commented Jan 24, 2024

The post/get/… methods are not defined in HttpClient but in its parent, requests.Session. HttpClient only explicitly overrides the generic .request() method (

def request(self, method, url, name=None, catch_response=False, context={}, **kwargs):
), which is called by the more specific methods (with *args and **kwargs forwarded automatically)

it would need explicit overrides for the specific methods, defining all the arguments. But that is kind of ugly/repetitive. Maybe it can be done in a if TYPING_CHECKING: section though.

@jasonwashburn
Copy link
Author

So, I didn't have any luck initially trying to create new methods to wrap get/put with types to make pylance happy, best I could do was keep pushing the pylance errors deeper into the locust code base. I was about to call it quits until I reread you comment and noticed the part about if TYPE_CHECKING which I'd missed previously. That actually seems promising...I was able to make the errors disappear just by adding the following to HttpSession in locust.clients 🤔 *Note: I didn't check to see what else might be missing for those methods, this is just proof of concept

if TYPE_CHECKING:

        def get(self, url, name=None, catch_response=False, **kwargs) -> ResponseContextManager:
            ...

        def put(self, url, name=None, catch_response=False, **kwargs) -> ResponseContextManager:
            ...

So, I suppose you could do it a number of ways...depending on how many cases of this there are in the larger codebase, you could define empty classes/methods with typing in a type checking block and then the real ones in the else block (but then you have to worry about keeping them synchonized with eachother)...or alternatively, handle them on a case by case basis by adding them in where necessary similar to the above?

In either case, it's something else that would need to be maintained if added, so certainly defer to you on the best approach, or if it's worth the squeeze at all. At the end of the day, I can always add a #type: ignore to my code as well. 😄

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the stale Issue had no activity. Might still be worth fixing, but dont expect someone else to fix it label Apr 18, 2024
@Akopov4
Copy link

Akopov4 commented Apr 28, 2024

When I hover mouse over get methods, to see available parameters it doesn't show appropriate list of parameters and it also sucks 👎

@tdadela tdadela linked a pull request May 4, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug stale Issue had no activity. Might still be worth fixing, but dont expect someone else to fix it
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants