I don't think there is other code that requires Python to actually set things in the context, so personally I wouldn't intuitively end up at this solution if I were looking for a way to do this.

How hard would it be to allow a poll function to return not only an "ok" boolean, but also a tuple ("ok", "reason")? As an alternative we could simply return a string and consider that short-hand for "false, and this is why", but to me that feels a bit dirty. I'd rather have the choice of returning one of True, False, or (False, "reason").

My concern with this patch is poll functions which are meant to be fast/simple will end up with string creation logic when it's not needed.

Scripts, especially developers that aren't considering performance could construct detailed explanations why poll fails, which will slow down poll functions.

I'd rather assign a callback than a string to allow delayed evaluation, e.g:

context.poll_disable_message(lambda: "some string")

Or...

context.poll_disable_message(detailed_function, optional_args_to_funciton)

@Sybren A. Stüvel (sybren) good points, I like your idea.
AFAIK the main reason the operator poll() doesn't take context as const is to be able to set the disabled hint. Eventually I'd like to see this addressed, and not having the Python code rely on this is a good idea I think, might save us some trouble later on.

RNA can return tuples, we just need to check how it can support either returning a tuple (boolean, string) or a single boolean, as we discussed in the chat.

Having extra optional return values has the down side that you couldn't reliably use a poll function from another operator, as changing the return value would cause if OtherOperator.poll(C): ... to always evaluate to true.

Even knowing what to expect is awkward to test:

poll_test = OtherOperator.poll(C)
if poll_test if isinstance(poll_test, bool) else poll_test[0]: ...

It also doesn't fit so well with delayed evaluation (although it could return a structure that would be evaluated later).

Submitted alternate patch that supports defering the evaluation and only allocates the string when it's needed: D11001

In D9738#280730, @Campbell Barton (campbellbarton) wrote:

Having extra optional return values has the down side that you couldn't reliably use a poll function from another operator, as changing the return value would cause if OtherOperator.poll(C): ... to always evaluate to true.

Good point, that's the death of my idea right there.

We could return a new PollResult object, which takes a boolean and a string, and with a __bool__ function that returns the given boolean. That'll make the truthyness check transparent.

It also doesn't fit so well with delayed evaluation (although it could return a structure that would be evaluated later).

A PollResult could handle this gracefully I think.