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

LSP type hinting #81

Open
darmstrong8008 opened this issue Jan 15, 2025 · 5 comments
Open

LSP type hinting #81

darmstrong8008 opened this issue Jan 15, 2025 · 5 comments

Comments

@darmstrong8008
Copy link

Hello! First of all, excellent work. After an agonizing afternoon trying to roll my own cookie solution for some personal projects, I remembered this project exists and gave it a whirl this morning -- this thing just works. Thank you!

Personally, I'm one of those people who are particulary peeved by LSP warnings, and I was curious if there was any downside to directly inheriting requests.Response in class RequestiumResponse(object)? Again, strictly for type hinting.

Doing this effectively silences the warnings from pyright when attempting to use the traditional response dot syntax for accessing these attrs from the original requests.Session class:

class Response:
    """The :class:`Response <Response>` object, which contains a
    server's response to an HTTP request.
    """

    __attrs__ = [
        "_content",
        "status_code",
        "headers",
        "url",
        "history",
        "encoding",
        "reason",
        "cookies",
        "elapsed",
        "request",
    ]

The only possible downside I can think of is that doing this would make Requestium more tighly linked with requests, but as it aims to be a "drop-in" replacement for it with the benefit of using a webdriver as-needed, that might not be such a bad thing?

Bare with me, I'd describe myself as an intermediate-level python programmer and I know this isn't strictly necessary with how the __init__ is written for RequestiumResponse, but inheriting requests.Response here does what I want.

I know I could just configure pyright for each project, but I see a lot of potential with this library regarding all of my other automation testing projects so there's a non-zero chance it will be used in many places :)

@lordjabez
Copy link
Collaborator

This makes sense to me. Still need to find time to implement, it though, unless you want to take a shot at it? If you do, you should start with the work @bmos has done to avoid merge issues later.

I really will get to giving this package some fresh attention soon. Had to get through the holidays.

@bmos
Copy link
Contributor

bmos commented Jan 18, 2025

I'd love another pair of eyes on #80! There are still three typing errors thrown by mypy I couldn't figure out but it's almost all there.

@darmstrong8008
Copy link
Author

Sure, I'll take a look when I find the time. I mainly use this account at my day job, so it may be a little while before I can dedicate my attention to it, but I'll keep you all posted.

@darmstrong8008
Copy link
Author

Just for quick clarification, I've literally just modified the RequestiumResponse class to explicitly inherit requests.Response in my user's site-packages:

class RequestiumResponse(requests.Response):

While this does what I initially wanted for a very specific use-case when using this class in a project, I'm sure there are other areas I haven't looked at yet.

@bmos
Copy link
Contributor

bmos commented Jan 23, 2025

There shouldn't be any downside to what you did, except when running Python 2, as the original "object" inherited there is assumed in Python 3.

https://stackoverflow.com/a/45062077

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants