Hi. Thanks for the PR!

I see that you explicitly use typing_extensions, which is not a dependency of PTB so far. We're generally trying rather strictly to keep the number of dependencies small so unless there is an overwhelming benefit in using it, I'd like to skip it.

Your changes also lead to a number of problems reported by mypy (see the pre-commit check). I haven't yet checked if they are genuine problems that surface due to improved type hinting or if some of them are due to problems in your changes.

Have you checked also the other options mentioned in microsoft/pyright#6669 (comment), i.e. using a typevar or no annotation at all, and how those behave with VSCode & PyCharm?

I see that you explicitly use typing_extensions, which is not a dependency of PTB so far. We're generally trying rather strictly to keep the number of dependencies small so unless there is an overwhelming benefit in using it, I'd like to skip it.

Have you checked also the other options mentioned in microsoft/pyright#6669 (comment), i.e. using a typevar or no annotation at all, and how those behave with VSCode & PyCharm?

I agree with you, and it seems that removing most of the type hinting annotation and leaving the static analysis tool do its job works.
EDIT: well, not exactly. As stated in the answer you linked, mypy is unable to infer the return type if not properly annotated. It is a matter of personal preferences, but I feel like proper type hinting is worth the extra package. Maybe it could be installed only when using versions of python < 3.10?
This said, there is a problem with the method itself: being inside the class, it is expected to have self as the first parameter.
Making it static creates problems with the documentation. Removing it from the class entirely may be the best option.

Your changes also lead to a number of problems reported by mypy (see the pre-commit check). I haven't yet checked if they are genuine problems that surface due to improved type hinting or if some of them are due to problems in your changes.

All of them seem to be genuine, and were quite easy to fix. The changes required are just in a few spots, so you can make sure everything is correct just by looking at the commits.

Is there a specific reason why input_chat_id in this line

is an object instead of the expected string or int?

@Bibo-Joshi yeah I am fine with the massively reduced complexity in favour of better type hinting. If people need more info about the called method they should just debug step into or write their own log lines in user level code

Instead of doing this via a decorator, we could that instead in a centralized place in _do_post

also agree with dropping the decorator.

@TendTo would you be interested in working on the alternative approach?

@TendTo would you be interested in working on the alternative approach?

I thought this would have been a matter of a few targeted changes, but I now see it is a bit more complex than that. I still want to give it a try, but since I am a bit busy, if someone can solve the issue faster, they are free to do so.

So, I tried following your advice of centralizing the logging in the method _do_post.
There are two ways I would use for logging the caller function: either logging the endpoint:

    async def _do_post(self, endpoint: str, ....):
        self._LOGGER.debug("Calling: %s", endpoint)
        ...
        result = await request.post(
            url=f"{self._base_url}/{endpoint}",
            request_data=request_data,
            read_timeout=read_timeout,
            write_timeout=write_timeout,
            connect_timeout=connect_timeout,
            pool_timeout=pool_timeout,
        )
        self._LOGGER.debug("Result from: %s", endpoint)
        self._LOGGER.debug(result)
        return result

or using the traceback provided by python:

    async def _do_post(self, endpoint: str, ....):
         # is this -4 always correct?
        self._LOGGER.debug("Calling: %s", traceback.extract_stack(limit=4)[-4].name)
        ...
        result = await request.post(
            url=f"{self._base_url}/{endpoint}",
            request_data=request_data,
            read_timeout=read_timeout,
            write_timeout=write_timeout,
            connect_timeout=connect_timeout,
            pool_timeout=pool_timeout,
        )
        self._LOGGER.debug("Result from: %s", traceback.extract_stack(limit=4)[-4].name)
        self._LOGGER.debug(result)
        return result

Based on the approach you prefer, there are a lot of tests that may need to be updated. E.g.

Definitely simply go with logging the endpoint. Trying to extract the traceback stack is a bit too complicated for such little benefit.