On 7/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Facundo]
> > The pre-PEP is almost done, and the corresponding
> > test cases are all written.
>
> What is the part about the pre-PEP? Something like this probably
> shouldn't go in the standard library until it has been proven in the
> field. This doubly true for a module that has made some unusual OO
Well, maybe the pre-PEP is not a good name.
My {name:concept} mapping for pre-PEP is something like "document that
has all the reasons, rationale and examples and everything like a good
PEP, but it's not a PEP yet (maybe never won't be)".
Making a pre-PEP, and not filling a bunch of other documents, is a
good way for me to document everything as it should be.
> * The exchange rate mechanism may end-up not being workable as it does
> not incorporate rate changes over time, differing forward and reverse
> rates, non-linear factors such as commission/fees, source currency, or
> multiple suppliers.
Are you talking about the exch_rate attribute of Currency? Our idea
for it is to record the necessary exchange rates, *at creation time*,
between the object's currency type and whatever you'd like to store.
> * Time value of money computations are typically dimensionless (not
> sensitive to currency type or formatting) and they often have algorithm
> specific rounding needs (round at the end of compounding period or each
> year or only at the end).
We think that it'd nice to have TVM functions inside a money module,
so if you want to do some math abouth this you just import the module
and use it.
It's not so much related to Currency data type, it's just that we
think that this module is the right place to put those functions.
Don't think that these generic functions use in some way the Currency
data type of its Context.
> * The absence of a division operator may prove problematic for
> allocation routines.
In what sense? I don't understand what you mean, sorry.
BTW, we take out the "/" operator because it's to tricky to use for
the final user. Being (in the context) dec_places=2 and
trap_inexact=True (both defaults), doing Currency(1)/2 is ok, but
doing Currency(1)/3 will give you an exception.
So, the idea is the user to don't have a division operator, for him to
have to look at distrib() method, and be aware of all the issues
involved.
Another concept we discussed here is that Currency() should do money
operations *only*, as safer as we could. If you want to start doing
some generic arithmetic operations, like calculating the average
between a list of prices, you should convert it to Decimal and use it
as a number and not a currency.
Take note that we're not against using currency as a number *if and
only if* it won't affect your currency behaviour (or safety).
> * Usually numeric formatting is kept independent from the rest of the
> design. It will be interesting to see how workable it is to make it
> part of the Context object. In Excel for instance, formatting is a
We put the formatting configuration in the context, because we thought
is the best way to store your config, change it for one thread, change
it for all threads, use a different formatting from another specific
context, etc... basically, the same liberty that gives you the context
for the other configuration, but for the formatting.
The formatting function itself will be a separate function in the code
(*cough* we'll use your function from Decimal recipe *cough*).
> While the Money module remains experimental, it should remain a
> third-party package.
Indeed! And maybe will still be a third-party package after it
finished being experimental.
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
