# Reliable way to find out the required context for an operator?

I already found this answer, where it was suggested that if you send an empty dictionary as override, it's supposed to show you what context elements are required to run the operator.

But this didn't work for the operator I'm interested in:

bpy.ops.cycles.use_shading_nodes({})

Traceback (most recent call last):
File "<blender_console>", line 1, in <module>
File "C:\Program Files\Blender Foundation\Blender\2.74\scripts\modules\bpy\ops.py", line 187, in __call__
ret = op_call(self.idname_py(), C_dict, kw, C_exec, C_undo)
RuntimeError: Operator bpy.ops.mesh.select_all.poll() failed, context is incorrect


So my question is, is there a reliable way to find out what the required context is for an operator? (The docs are no help here. Source might be, but I'd rather avoid that search for a needle in a haystack unless I'm really desperate...)

• Yeah the source is the definitive answer: I think you allude to this question ( blender.stackexchange.com/questions/30364/… ) . But you probably don't want this in the first place. Is your real problem ' i want to create a material and set it to use shader nodes - via script ' ? – zeffii Aug 13 '15 at 15:51
• Thanks. Unfortunately I do indeed want to set the background material to use nodes via a script... I hope someone will have another idea that doesn't involved delving into the source, but if there's no choice, it won't stop me :) – TLousky Aug 13 '15 at 15:55
• It really comes down to people trying to use operators that aren't intended to be used anywhere other than as a response to a user clicking a menu item. During that menu interaction the operator has the correct context, but outside of it.. in a script for instance..which tends to have a sort of 'no-mans-land' (or very often the wrong ) context.. it will fail. Looking for a way to override the context, for every possible operator, is not necessary, as the context limitation is often mitigated by using more low level bpy calls. (In the end also this results in more manageable code.. ) – zeffii Aug 13 '15 at 16:17
• This ties into my "bpy.ops has cooties" philosophy. In an ideal world each function in bpy.ops would clearly document the context it requires, but it would be a major effort to update all the docs. Even requiring that documentation for new operators would encounter resistance from the coders who are working full-tilt to keep the bugs under control while adding important new features. – Mutant Bob Aug 13 '15 at 17:45

Asking for a way to find the context for all possible operators that need such an override is at the same time ignoring all the responses to people looking for their specific override for their needs.

As is often the case with 'context is incorrect', there is a solution that's much simpler and (more) logical than the potential workaround using context overrides. While most operators can take an override context, you will invariably (if you dig deep enough) find several that can't. You will also find operators which are the only way to achieve some goal.

For all other cases where there's a better way to do it without the operator in question, you simply use the lower level bpy code. Ask, we will always give an answer, or dig using the Info console and track the changes in bpy.data to see what got added and which parameters are adjusted after a manual Operator invoke (ie you click a button, and that calls the operator in question).

(Sometimes a context override is the only way, but not this time)

Make a new world material.

>>> m = bpy.data.worlds.new('amazon')
>>> m.use_nodes = True
>>> m.node_tree