prePEP: Money data type

[Alex Martelli]

Ian Bicking wrote:
   ...
> For instance, Money.parse('$100.00'), Money.parse('$100.00',
> decimalSeparator='.'), Money.parse('100Y', currency='Y'), etc.

I like the idea of delegating ALL build-by-parsing-string functionality
to a Money.parse classmethod -- it nicely matches my suggestion of
delegating any fancy emit-string functionality to a .format instance
method.  This would let Money.__init__ (or Money.__new__, whatever)
remain simpler, without need for "decimal separators" etc.


> Also, while you can use potentially ambiguous heuristics for this parse
> constructor, the main constructor can be more strict -- it's hard to
> add strictness, but easier to take it away.  I would expect that the

Yes, just as for functionality.

> main constructor take only a string or a number-like-object (int,

Actually, if Money's main ctor did not take ANY string at all, how
would that be bad?  An explicit Money.parse in the base ctor can take
care of that.  The reason we don't have this in existing built-ins is
that existing built-ins were designed BEFORE we had classmethods, so
their ctor was "the" ctor, singular, so it was badly overloaded.  But
these days we can do better.

> float, fixed point, etc), with other information passed through keyword
> arguments.  I would prefer the string be a Python style of number,
> i.e., unambiguously and strictly with '.' for decimals, and no
> thousands-separator.  But then that matches my locale, so I suppose I'm

The Italian locale is different, but I would have no objection to
Money.parse in the base class being very spare.  It should roughly
match the functionality of the .format instance method in the base
class: more or less, what .format can emit .parse should be able
to use, when each is given appropriate keyword arguments (locale or
a localeconv-like dict, indications of whether to use plain or money
and base or international settings) -- but it WOULD be fine if that
functionality was quite limited, including nothing at all fancy, in
the base class (a subclass or perhaps better a mixin SHOULD however
also be provided in the module, with at least locale-based parse
and format abilities).

> biased -- but I see the sole reason for using that string to be that
> Python float literals cannot precisely express a fixed-point number.
> If a fixed-point literal existed, then I would prefer that no string be
> allowed -- the parse constructer better highlights what is being done
> in that case.

Upon reflection I prefer no string in the main ctor anyway -- float
literals CAN express numbers to at least about 16 digits and we don't
really need more in most cases (when we do, passing a long and a
scale factor such as scale=2 to indicate the long is in /100th's
seems quite OK).  Of course a float would be rounded-to-nearest to
the indicated or defaulted amount of precision, AND it should be a
ValueError if the rounding is one ULP or more, because that would
surely indicate it wasn't a _literal_ that was passed.


> (A fixed-point literal would be quite nice... a fixed-point builtin
> would be quite nice...)

Yeah, but so would be sets -- first we need to get into the standard
library (and the sparest, simplest base class we can make, the more
likely I judge we can get into the standard library), THEN once the
type is in use we can make a case for literals and builtins.


Alex