Consistent handling of properties in Python wrappers

[schnellerhase]

The Python wrappers require in some cases an additional wrapping to return the appropriate Python type. This can be achieved in multiple ways, but should be consistent throughout.

For example the FunctionSpace_float32/float64.element function returns a FiniteElement_float32/float64, in the Python API however these types are not exposed directly but only the corresponding wrappers FunctionSpace and FiniteElement. This means that at some point of the (wrapped) FunctionSpace.element call we need to switch to the wrapped FiniteElement type.

The question is then, how this should be (consistently) facilitated across the Python layer, see also the discussion at #3542 (comment). Options are

1. Python wrapper maintains a (wrapped) member variable that is exposed through the API:

   • Single time construction of wrapper (during construction of super class).
   • Requires additional state that needs to be managed/maintained - updates in cpp layer need to be propagated.
   • Currently used for example in dolfinx.mesh.Mesh

2. Construct wrapped object during access

   • Simple syntax in python wrapper.
   • Produces different objects with different calls, resulting in non consistent behavior for address checking, see Add FiniteElement python wrapper #3542 (comment)

3. Use of cached_property to maintain a single instance without explicit management.

   • Resolves the problem of memory addresses of 2.
   • Property accesses imply lookup - cached_property documentation states it should be used for "Useful for expensive computed properties of instances that are otherwise effectively immutable." - Python wrappers are however always lightweight and how correct is the immutable assumption?
   • Currently used in dolfinx.fem.FunctionSpace

To resolve this one needs to decide on a consistent style, adapt it throughout and maybe document it in the developer resources