Quantity
should be an abstract base class
#821
Labels
part:actor
Affects an actor ot the actors utilities (decorator, etc.)
part:core
Affects the SDK core components (data structures, etc.)
part:data-pipeline
Affects the data pipeline
scope:breaking-change
Breaking change, users will need to update their code
type:enhancement
New feature or enhancement visitble to users
Milestone
What's needed?
We should not allow to use a plan
Quantity
without any associated... quantity, as that's just afloat
.Proposed solution
Make
Quantity
a ABC.Use cases
No response
Alternatives and workarounds
No response
Additional context
The solution is probably much more complex than that, as I believe we allowed to construct "abstract quantities" to overcome complications with the type system, in particular related to
Sample
s, that sometimes need to have afloat
value and sometimes aQuantity
.I've been investigating different approaches:
Making
Sample
type parameter bound tonumbers.Real
. This didn't work because brilliantly,isinstance(1.0, Real) is True
, but usingT = TypeVar("T", Real)
is not good enough to the passfloat
asT
(the types don't match). This seems to be a know bug that will not be fixed, as it seemsnumbers
were created before type hints to solve some other problem. In any case, it will be also very hard to makeQuantity
be a properReal
, because we can't allow all operations (for example, if we multiply a quantity by the same type of quantity, we get quantity², not quantity, so we can't generally allow it.Building our own
RestrictedFloat
type, or something like that, to make it compatible withfloat
. This sort of works, but when looking at how much restricted afloat
needs to be to be aQuantity
, there is not much left. It is basically comparison, addition and scaling.Making
Quantity
convertible tofloat
(implement__float__()
). This seems to be the most sensible solution. By doing this the most important operations inmath
related to floats that we need to do in the most generic places even work without conversion, likemath.isnan()
andmath.isinf()
, so we can treatQuantity
s asfloat
directly for that and remove theisnan()
andisinf()
methods, being able to work withfloat
andQuantity
in a generic way. For other math, we can dov = float(quantity)
and then do whatever math we need withv
in a generic way. Of course we generally don't want users to convert tofloat
, this is why we have all theas_xxx()
methods, but when used generically, like in the resampler, we know we are working with the same type of quantity always, so it is safe to convert tofloat
. Also making operations that escape the quantity (like v * v), should not make sense in resampling functions, because the new sample always need to be in the same quantity as the input samples, so that should never happen because of how math works.The text was updated successfully, but these errors were encountered: