Inconsistency in inheritance structure and make_node

[ferrine]

The make_node in the base Op class is meant to deal with class Variable which in turn has a base Type class. In a number of places we violate the principle of common interface for this type structure.

1. There are numerous as_tensor_variable in the codebase, just scroll down this
2. Implement specific checks for inferring the just right type in the make_node

   pytensor/pytensor/tensor/random/basic.py

   Line 1914 in d798553

   def make_node(self, rng, *args, **kwargs):

3. we make redundant checks according to the signature we have
4. we also assume more about the type than it should be (here the above isinstance should actually be TensorType) because Variable does not have any ndim, that is a property of TensorType and could actually be a property from HasShape
5. HasDytpe looks also suspicious and violates type structure, it declares dtype: str later on every sublcass picks up this dtype, compares to numpy dtype and creates an attribute with numpy_dtype (there are just three places HasDType is Inherited)

   1. pytensor/pytensor/scalar/basic.py

      Line 272 in d798553

      class ScalarType(CType, HasDataType, HasShape):

   2. pytensor/pytensor/tensor/type.py

      Line 58 in d798553

      class TensorType(CType[np.ndarray], HasDataType, HasShape):

   3. pytensor/pytensor/sparse/type.py

      Line 36 in d798553

      class SparseTensorType(TensorType, HasDataType):

      (it even inherits the HasDtype twice)
   4. the function dtype_spec is defined outside of HasDtype in every inherited class

      1. pytensor/pytensor/scalar/basic.py

         Line 373 in d798553

         def dtype_specs(self):

      2. pytensor/pytensor/tensor/type.py

         Line 279 in d798553

         def dtype_specs(self):

      3. pytensor/pytensor/tensor/type.py

         Line 40 in d798553

         dtype_specs_map = {

      4. pytensor/pytensor/sparse/type.py

         Line 51 in d798553

         dtype_specs_map = {

   5. I guess all the dtype specific things utterly have to be in a single consolidated space, the HasDtype class or HasNumpyDtype as every single class uses this property to ensure numpy dtype is present there. Inheritance means more than having a dtype string and similar checks are done in every place.
   6. TensorType seems to be the entry point of classes that both have dtype and shape and is the most generic, however, seemingly more specific class ScalarType is not a subclass of the TensorType which seems weird issubclass(ScalarType, TensorType) is False, but in fact, TensorType is a superset of the TensorType
   7. The shape TensorType seems to be uniform across all the codebase and is a subset of TensorType which is lvector with fixed length Creating Shape(TensorType) makes total sense since more structure is asserted in this instance: fixed dtype + fixed shape
      1. there is also inconsistency with input types, a generic variable is considered as input but only HasShape typed classes are valid for taking shape, isn't it?

[ricardoV94]

About types, this might be relevant: aesara-devs/aesara#1207

And the associated issue (and its "off-topic" comments): aesara-devs/aesara#134

[ferrine]

yeah I was thinking of similar things