Value object API changes and use of decimal.Decimal about nautilus_trader

[mLewisLogic]

I'm in favor of this change overall. It gets us out of the business of maintaining something as generic as a Decimal implementation. Bummer that we lose some of the ability to cleanly specify type, but seems like a minor cost.

In general, if you're performing a binary operation and one of the operands has a weaker specification than the other, then the result should be limited by the weaker specification. In this case, a float is a weaker specification (due to imprecision) than a Decimal, so a binary op between a float and a Decimal should render a float to avoid casting surprises.

Seems like Decimal() + float() is going to work. How about float() + Decimal()? Might be tricky to get that working. Ultimately a simple fix, but may be an implementation-specific gotcha for users.

[mLewisLogic]

Does raising a TypeError when the BaseDecimal constructor is passed a float value with no precision passed seem like expected and reasonable behavior?

Probably fine either way. I could think of cases where you want to wrap it in Decimal just to combine with another prior to a round. In which case, specifying precision has no purpose. Could make things safer or more explicit though.

[cjdsellers]

Bummer that we lose some of the ability to cleanly specify type, but seems like a minor cost.

There's still scope to add value types as appropriate if there's enough of them, I think there's not too much proliferation of checking for decimal.Decimal types throughout the codebase right now, but we'll keep an eye on it.

In general, if you're performing a binary operation and one of the operands has a weaker specification than the other, then the result should be limited by the weaker specification. In this case, a float is a weaker specification (due to imprecision) than a Decimal, so a binary op between a float and a Decimal should render a float to avoid casting surprises.

That's a good way of putting it, I agree this is the correct approach - so I'll leave as is.

Seems like Decimal() + float() is going to work. How about float() + Decimal()? Might be tricky to get that working. Ultimately a simple fix, but may be an implementation-specific gotcha for users.

This actually works, and is tested for in the unit tests. For something like the below

def __add__(self, other)

The self and other param names are just standard conventions, the first argument is always the operand on the left of the expression even if that's not self, which is confusing I know. I noticed @scoder actually uses something more akin to a, b for the names. However, when I tried this I found PyCharm doesn't like it, so I just stick to self, other.

[cjdsellers]

Does raising a TypeError when the BaseDecimal constructor is passed a float value with no precision passed seem like expected and reasonable behavior?

Probably fine either way. I could think of cases where you want to wrap it in Decimal just to combine with another prior to a round. In which case, specifying precision has no purpose. Could make things safer or more explicit though.

We'll keep this in mind if the scenario pops up regularly somewhere.