Unintuitive class behaviour

[andrewgsavage]

The technical guide states UFloat is the recommended class to use for isinstance checks.

1. I expected the type of UFloat to be UFloat, not AffineScalarFunc

from uncertainties import unumpy, umath ,ufloat, UFloat
UFloat
uncertainties.core.AffineScalarFunc

2. I expected the output of ufloat to be a UFloat, or at least a AffineScalarFunc since that's what I imported.

u = ufloat(1, 0.01)
type(u)
uncertainties.core.Variable

3. When I add two ufloats together, I go from a Variable to an AffineScalarFunc. Given the name ufloat, I expect these objects to behave similarly to a float and return the same type as the original object.

v = u + u
type(v)
uncertainties.core.AffineScalarFunc

It would be more intuitiave for the class the user sees to be called UFloat.

Could a single class be exposed to the user, rather than Variable and AffineScalarFunc?

[andrewgsavage]

I might suggest also inverting the use of UFloat as an alias for AffineScalarFunc. That is, I think the main interface and way of thinking of the basic object is as a UFloat, and the name "AffineScalarFunc" is slightly odd and confusing to see in exceptions.

Reading through https://pythonhosted.org/uncertainties/tech_guide.html#python-classes-for-variables-and-functions-with-uncertainty
I'm thinking:

AffineScalarFunc -> UExpression
Variable -> UFloat
ufloat() -> UFloat(), ie the class' __init__

With documentation instructing users to use UExpression for isintance checks and that UFloat is a subclass of UExpression