docs/stdlib/data: use :py: role. NFC

docs/stdlib/data.rst

@@ -112,7 +112,7 @@ For example, consider a module that processes RGB pixels in groups of up to four
                       * i_stream.valid[n]
                       for n in range(len(i_stream.valid))))
 
-Note how the width of ``i_stream`` is never defined explicitly; it is instead inferred from the shapes of its fields.
+Note how the width of :py:`i_stream` is never defined explicitly; it is instead inferred from the shapes of its fields.
 
 In the previous section, the precise bitwise layout was important, since RGB565 is an interchange format. In this section however the exact bit positions do not matter, since the layout is only used internally to communicate between two modules in the same design. It is sufficient that both of them use the same layout.
 
@@ -155,7 +155,7 @@ In case the data has related operations or transformations, :class:`View` can be
         def brightness(self):
             return (self.red + self.green + self.blue)[-8:]
 
-Here, the ``RGBLayout`` class itself is :ref:`shape-like <lang-shapelike>` and can be used anywhere a shape is accepted. When a :class:`Signal` is constructed with this layout, the returned value is wrapped in an ``RGBView``:
+Here, the :py:`RGBLayout` class itself is :ref:`shape-like <lang-shapelike>` and can be used anywhere a shape is accepted. When a :class:`Signal` is constructed with this layout, the returned value is wrapped in an :py:`RGBView`:
 
 .. doctest::
 
@@ -203,7 +203,7 @@ For example, consider a module that can direct another module to perform one of
             })
         })
 
-Here, the shape of the ``Command`` is inferred, being large enough to accommodate the biggest of all defined parameter structures, and it is not necessary to manage it manually.
+Here, the shape of the :py:`Command` is inferred, being large enough to accommodate the biggest of all defined parameter structures, and it is not necessary to manage it manually.
 
 One module could submit a command with: