monetary applications (et al)

[Alex Martelli]

terry wrote:

> 
>>>> Michael wrote:
> for how to emulate numeric types.
>>>>
> 
> Right, I have looked at that.  As near as I can tell there is a vast
> difference between 'emulation' and 'intrinsic' - and the burden of that
> difference falls on the programmer/customer in your assessment.  The

I don't understand what you mean.  Where's the "vast difference",
and what burden falls on the "programmer/customer"?  If a type is
not built-in (e.g.: cStringIO.StringIO, array.array, mmap.mmap, to
mention a few non-intrinsic types distributed with core Python),
then you need an "import something" statement.  That's not deeply
different from, e.g., needing an "import math" before you can
compute trig functions (then you call math.sin, of course, not
just sin).  Is *THIS* what you consider "a vast difference"???  I
can't think of anything else.

Python users who need to compute trig functions have never squealed
out load about the intolerable burden of having to "import math"
to do so.  On the contrary, people with such needs have developed
a large, now widespread package called Numeric, which supplies a
zillion facilities for such computations, and is used as a base by
a large number of other, mode specialized computational modules.

This substantial minority of Python users start almost all of their
Python programs with "import Numeric" or "from Numeric import".

Doesn't seem to have done any damage to Python's standing in the
field of scientific computation -- on the contrary, decoupling the
computational parts from Python's core allows the two parts to
evolve and get released independently, thus benefiting both those
who need such advanced maths, and those who couldn't care less.

So what distinguishes the set of people who'd like a "currency"
type from those who wanted advanced numerical maths -- except
maybe that one set is more inclined to whining, the other, to doing
something about it...?


Alex