Hi. I would vote to say this is the responsibility of the end user. Easy enough to do in code:

callback(update, context):
    text = "This is the text to get to the user"
    if update.effective_message:
        update.effective_message.reply_text(text)
    else:
        update.callback_query.edit_message_text(text)

Or even more if statements if you have more potentially callbacks. Thats easy to know because you register them with specific handlers, normally.

Sure, its easy enough to do. Just thought it can be a common issue, as I've had it several times :)

It might be, though I personally define one callback per handler type.

Anyway, I don't think the library should just switch methods for the user. This is not the responsibility of it.

Alright, should I close the issue then?

You can leave it up if you are still convinced its a good idea and see what the other maintainers think.

Hi. The update.effective_message already covers update.callback_query.message, i.e. one doesn't need the if clauses in Pools example. IMO this already covers the requested use case.

Note that there is also update.effective_{user, chat}, which in particular covers the from_user case.

Ohh, I wasn't aware that covers them all! That makes things much easier. Thanks :)
Then perhaps maybe we could make the docs a bit clearer on what effective_{} do? it does say "no matter what kind of update this is", but maybe it could mention all the various things it checks? e.g whether it be message, edited message, callback_query, etc.

If you think that's a helpful addition, I could make that change. Otherwise I'll just close the ticket :)

We list the updates which set it here, where is your string from?

Yes, that's where I got it from. It says it will be none for this and that. It doesn't say that it will return whichever of message, edited_message, callback_query, channel_post, edited_channel_post that is present.

@evakdev Ohh you mean instead of saying when it is None, you would say when it is the message?

yes, exactly! it could say both too, actually

If you like to, you're very welcome to open a PR against the doc-fixes branch to elaborate the docs :)

I added the doc-enhancement to #2633 and will close this thread in favor of #2633 :)

FYI: I added a commit to #2822 that addresses the documentation. For effective_{user, chat}, I didn't list every possibility, but included exapmles that should get the idea across better :)