failed to figure out how to multiple unity number by unitless number

[zooko]

I had a unity number stored in a variable named T1, and then I did this::

>>> from decimal import Decimal
>>> D=Decimal
>>> D('0.16') * T1 - O1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'Decimal' and 'Dimensional_Units_1'

I had expected it to multiple T1 by the (dimensionless) 0.16 for me.

Allegedly there is a way to do this in dimana, using dimana.Dimensional('0.16) instead of Decimal('0.16'). So I have several requests/suggestions:

1. The initial docs for dimana should mention how to create dimensionless numbers.
2. Waitaminute, the way to create a dimensionless number is with a constructor named Dimensional? That sounds wrong.
3. Is there a reason not to promote Decimals automatically to Dimensionlesses? I guess there's a risk that a user would have a number stored in a Decimal when they intended it to be a dimensioned number, like the number of Frobs, and forcing them to explicitly put Dimensionless('0.19') would let them realize that they actually need Dimensional.get_dimension('Frobs'). But I'm skeptical—why does Dimensionless('0.19') help them notice that any better than Decimal('0.19') helps them notice?

[nejucomo]

Waitaminute, the way to create a dimensionless number is with a constructor named Dimensional? That sounds wrong.

Dimensional is an abstraction with a particular API, so I plan to change the name to Dimana so that this doesn't sound weird to any users. The way I thought of it previously, a Dimensional quantity without units is similar to a matrix with 0 dimensions. These might all be the same mathematically, but I prefer APIs that disallow me from passing a 0-dimensional numpy instance where a float is expected, or elsewhere where an int is expected, and so on.

Coercion is nice in the interactive interpreter, but in my experience, in written code it leads to a heavier burden on tracing back to actual calling code to understand the effects of code within a callee, so whenever it's possible to create simplifying assumptions in the API, I prefer that.

This is part of the purpose of dimana! The other big part, for me, is for me, as a human, to either verify or query the units that result from some computation.

I'd like to add a new separate layer which makes it more convenient to use dimana in an interactive interpreter, so that application code can then choose whether to be explicit or writer-convenient.

I'm marking this ticket as closed because I consider the newly created tickets and this explanation to cover this issue. Let me know if I'm missing anything.

[nejucomo]

@zooko, do you primarily use dimana in interactive interpreter sessions?

That's my primary use so far, although I would like to begin using it in applications as a library.

[zooko]

Yes, I have been using it in the interpreter.