Interesting idea. Still have to look at it in more detail, but makes sense generally. I wonder if this should be the preferred method for overriding the context if it is accepted (instead of creating a`dict` that contains the overrides).
As for the naming, I think just override is better than temp_override. The fact that it returns a context manager indicates that it is supposed to be used in a temporary scope.

Found it funny how the patch uses a context manager to actually manage context.

While not opposed to the general idea here, I wonder why current context override is not working/good enough in that case?

And am not very happy with using just override as name here either, we already use override in a very different meaning in ID data... Would suggest to either be more verbosely explicit (context.context_override() ?), or use a different name altogether for context override (supersede ? replace ?).

We already suffer from our multi-usages of collection e.g., think we should try to avoid that kind of issues as much as possible?

In D13126#346969, @Bastien Montagne (mont29) wrote:

While not opposed to the general idea here, I wonder why current context override is not working/good enough in that case?

Two reason:

• Those overrides are only used when calling operators, it's possible we may want to set the context outside of operators, although we could support this exact style of overriding context members with a context manager (without actually setting the active window, area... etc).

• These set up overrides that work by accessing from the context will override. e.g. CTX_data_active_object(C) where as using BASACT(view_layer) wont.
  
  In principle it could be argued that's the context should always be used removing the need for this feature.
  
  In practice there is enough code that uses direct access to window/screen/scene, e.g. WM_window_get_active_scene(C) / WM_window_get_active_screen(C) .. etc.
  
  Temporarily swapping out windowing context is done quite a lot in Blender's C code: P2725.

We could change how operator overrides work (with this API https://docs.blender.org/api/master/bpy.ops.html#overriding-context so these changes actually temporarily modify the values of C.wm.* for example. This has pros and cons and could back-fire in some cases (specifically when restoring the original value overwrites a change which the user wished to keep from the resulting operation) - although we could detect this and only restore values that are unmodified by the operator - it feels quite fragile.

Another down side is that only some members will be temporarily assigned (at least initially), adding support for members has the potential for subtle changes in behavior that could break scripts.

Note that if this were done we would still want a context manager to override the context members outside the operator (not a problem, just mentioning).

And am not very happy with using just override as name here either, we already use override in a very different meaning in ID data... Would suggest to either be more verbosely explicit (context.context_override() ?), or use a different name altogether for context override (supersede ? replace ?).

We already suffer from our multi-usages of collection e.g., think we should try to avoid that kind of issues as much as possible?

Agree although logically it _is_ an override, it's not all that helpful to use that term in this context (no pun inten... sigh :) ).

Possible alternative could be "state", e.g. with context.temp_state(..): ....

Open topics:

• In principle, would it be better to follow the current context override API? (assuming the details can be figured out).
• Would this be limited to window manager members or would we eventually want to extend this to active object, bones .. etc?
• Might we be better off with a more limited solution that handles the case of loading a file not having an active window (personally rather more general solution, mentioning for completeness).

Perhaps best to discuss this in chat, since there are various ways we could handle this.

In general, getting something like this to work would be quite nice. I've seen plenty of cases where a general way to override context would've made things easier.

My main worry is also code that mixes context access with direct access. I just see too many things that can break, and it's a bit fragile.

In D13126#366534, @Campbell Barton (campbellbarton) wrote:

In principle it could be argued that's the context should always be used removing the need for this feature.

I'd strongly argue against this. IMO context should be passed around as little as possible, because otherwise there is going to be a lot of code depending on it, it gets annoying and dirty. We'll have to pass it around through multiple layers just because some function deep down the call stack requires it, and we'll end up with more evil_C usage and access. It's also not clear what context functions expect -- "is the context region required, or just the area?? Oh, this actually uses the scene, I didn't expect that..."
What I'd like to move towards is, operators use context to extract the data to operate on, then they hand that as input to functions. Make it clear what functions operate on.

Of course another thing we can do, is just add more functions to execute instead of the operators.

@Julian Eisel (Severin) Not sure I get your point about not using context as much as possible... I would rather say the opposite, context should be used as much as possible (just like

Had a chat with Campbell this morning, we considered quite a few alternative solutions, conclusions are:

• naming: temp_override is fine, this is a very specific use-case so it's fairly unlikely to create confusion with the 'data' override cases (library override, dynamic override, etc.).
• Proposed solution is fine, but should be extended to cover also the 'random keyword' context override currently provided by the override_context positional argument of operator calls, Then this later option can be deprecated and removed in a few releases.
• If current behavior to always reset to original values on exit is kept, it should be clearly documented, as it can have unexpected effects on results of operators that would e.g. change the active window/area/region (since it would undo that change).
• Might need some closer check on modal operators, although it should work in a similar way as current behavior when calling with an override_context defined (i.e. the operator is responsible to store whichever data it needs to be persistent over its modal execution).

In D13126#346368, @Jacques Lucke (JacquesLucke) wrote:

As for the naming, I think just override is better than temp_override. The fact that it returns a context manager indicates that it is supposed to be used in a temporary scope.

Not ignoring your comment but mont29 felt strongly about this, and personally I'm not that fussed.