prePEP: Money data type

[Ian Bicking]

On Saturday, October 18, 2003, at 12:57 PM, Alex Martelli wrote:
> Ian Bicking wrote:
>> On Friday, October 17, 2003, at 06:39 PM, John Roth wrote:
>>> 1. I've seen lots of strange rounding policies in
>>> various nooks and crannies. Is there any way of
>>> specifying a rounding policy that would be used
>>> and inherited by the result money object?
>>
>> Does the rounding policy belong to the money, or to the context in
>> which the money is used?  I would expect it belongs to the context,
>> which would imply the policy should be specified by method name or an
>> argument to a method.
>
> So you think y=x/2 should not work when x is an instance of Money,
> nor should y=x*z when x is an instance of Money and z is e.g. 0.5?
> That seems pretty limiting to me.

I could go either way.  Or rather I'd like both.  If I was doing 
serious accounting programming I *absolutely* would want money*0.5 to 
raise an exception -- I would want to be very explicit about anything 
that had the potential of being imprecise.  It would simply be too easy 
to mess this up otherwise.

If I was a more casual user of Money (which is actually all that I'm 
likely to ever be) then I would be annoyed by that preciseness.

In this circumstance, it would be reasonable for me to make my own 
money subclass to use in my application, if I wanted to avoid rounding 
errors.  Or, if an option were available for forcing explicit rounding, 
that would also work.  (But in most cases I wouldn't suggest 
subclassing as a feasible means of customization, e.g., for defining a 
standard rounding method -- subclassing for customization sucks)

>> No, the only places where repr() round trips is for Python literals.
>
> Not true:
>
>>>> from sets import Set
>>>> a = Set('ciao')
>>>> print a
> Set(['i', 'a', 'c', 'o'])
>>>> therep = repr(a)
>>>> b = eval(therep)
>>>> print b
> Set(['i', 'a', 'c', 'o'])
>>>>
>
> repr + eval "round-trips" for many types that don't have Python
> literals, net of the issue of whether the type's name as given
> by repr includes the module name (and thus roundtrips after an
> import statement) or doesn't (and thus roundtrips after a from
> statement) -- it seems that it more often doesn't.

Okay, what I said was not entirely true.  I was just concerned that the 
repr() of a money object *must* be readable -- sacrificing readability 
for accurate round-tripping is not acceptable.  It seemed like John was 
suggesting that.  repr() should not take the place of pickle.dumps()

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org