user: Show practical ways to work with Stale Data in a Blender add-on or script – include code.

assistant: ### No updates after setting values

Sometimes you want to modify values from Python and immediately access the updated values, e.g:
Once changing the objects [`bpy.types.Object.location`](bpy.types.Object.html#bpy.types.Object.location "bpy.types.Object.location")
you may want to access its transformation right after from [`bpy.types.Object.matrix_world`](bpy.types.Object.html#bpy.types.Object.matrix_world "bpy.types.Object.matrix_world"),
but this doesn’t work as you might expect. There are similar issues with changes to the UI, that
are covered in the next section.

Consider the calculations that might contribute to the object’s final transformation, this includes:

- Animation function curves.
- Drivers and their Python expressions.
- Constraints
- Parent objects and all of their F-Curves, constraints, etc.

To avoid expensive recalculations every time a property is modified,
Blender defers the evaluation until the results are needed.
However, while the script runs you may want to access the updated values.
In this case you need to call [`bpy.types.ViewLayer.update`](bpy.types.ViewLayer.html#bpy.types.ViewLayer.update "bpy.types.ViewLayer.update") after modifying values, for example:

```
bpy.context.object.location = 1, 2, 3
bpy.context.view_layer.update()
```

Now all dependent data (child objects, modifiers, drivers, etc.)
have been recalculated and are available to the script within the active view layer.

### No updates after changing UI context

Similar to the previous issue, some changes to the UI may also not have an immediate effect. For example, setting
[`bpy.types.Window.workspace`](bpy.types.Window.html#bpy.types.Window.workspace "bpy.types.Window.workspace") doesn’t seem to cause an observable effect in the immediately following code
([`bpy.types.Window.workspace`](bpy.types.Window.html#bpy.types.Window.workspace "bpy.types.Window.workspace") is still the same), but the UI will in fact reflect the change. Some of the
properties that behave that way are:

- [`bpy.types.Window.workspace`](bpy.types.Window.html#bpy.types.Window.workspace "bpy.types.Window.workspace")
- [`bpy.types.Window.screen`](bpy.types.Window.html#bpy.types.Window.screen "bpy.types.Window.screen")
- [`bpy.types.Window.scene`](bpy.types.Window.html#bpy.types.Window.scene "bpy.types.Window.scene")
- [`bpy.types.Area.type`](bpy.types.Area.html#bpy.types.Area.type "bpy.types.Area.type")
- `bpy.types.Area.uitype`

Such changes impact the UI, and with that the context ([`bpy.context`](bpy.context.html#module-bpy.context "bpy.context")) quite drastically. This can break
Blender’s context management. So Blender delays this change until after operators have run and just before the UI is
redrawn, making sure that context can be changed safely.

If you rely on executing code with an updated context this can be worked around by executing the code in a delayed
fashion as well. Possible options include:

> - [Modal Operator](bpy.types.Operator.html#modal-operator).
> - [`bpy.app.handlers`](bpy.app.handlers.html#module-bpy.app.handlers "bpy.app.handlers").
> - `bpy.app.timer`.

It’s also possible to depend on drawing callbacks although these should generally be avoided as failure to draw a
hidden panel, region, cursor, etc. could cause your script to be unreliable