[Mlir-commits] [mlir] [mlir][docs] Migrate code examples to nanobind, make Python spelling … (PR #163933)

[Jacques Pienaar]

================
@@ -219,23 +219,23 @@ Due to the validity and parenting accounting needs, `PyOperation` is the owner
 for regions and blocks. Operations are also the only entities which are allowed to be in
 a detached state.
 
-**Note**: Multiple `PyOperation` objects (i.e., the Python objects themselves) can alias a single `mlir::Operation`. 
-This means, for example, if you have `py_op1` and `py_op2` which wrap the same `mlir::Operation op` 
+**Note**: Multiple `PyOperation` objects (i.e., the Python objects themselves) can alias a single `mlir::Operation`.
+This means, for example, if you have `py_op1` and `py_op2` which wrap the same `mlir::Operation op`
 and you somehow transform `op` (e.g., you run a pass on `op`) then walking the MLIR AST via either/or `py_op1`, `py_op2`
-will reflect the same MLIR AST. This is perfectly safe and supported. What is not supported is invalidating any 
-operation while there exist multiple Python objects wrapping that operation **and then manipulating those wrappers**. 
-For example if `py_op1` and `py_op2` wrap the same operation under a root `py_op3` and then `py_op3` is 
-transformed such that the operation referenced (by `py_op1`, `py_op2`) is erased. Then `py_op1`, `py_op2` 
-become "undefined" in a sense; manipulating them in any way is "formally forbidden". Note, this also applies to 
-`SymbolTable` mutation, which is considered a transformation of the root `SymbolTable`-supporting operation for the 
-purposes of the discussion here. Metaphorically, one can think of this similarly to how STL container iterators are invalidated once the container itself is changed. The "best practices" recommendation is to structure your code such that 
+will reflect the same MLIR AST. This is perfectly safe and supported. What is not supported is invalidating any
+operation while there exist multiple Python objects wrapping that operation **and then manipulating those wrappers**.
+For example if `py_op1` and `py_op2` wrap the same operation under a root `py_op3` and then `py_op3` is
+transformed such that the operation referenced (by `py_op1`, `py_op2`) is erased. Then `py_op1`, `py_op2`
+become "undefined" in a sense; manipulating them in any way is "formally forbidden". Note, this also applies to
+`SymbolTable` mutation, which is considered a transformation of the root `SymbolTable`-supporting operation for the
+purposes of the discussion here. Metaphorically, one can think of this similarly to how STL container iterators are invalidated once the container itself is changed. The "best practices" recommendation is to structure your code such that
----------------
jpienaar wrote:

Could you wrap this line to match the others?

https://github.com/llvm/llvm-project/pull/163933