People: The Money two-days sprint in EuroPython 2005 has finished. We advanced a lot. The pre-PEP is almost done, and the corresponding test cases are all written. We need to finish the structure procesing for currency general information, and bring general functions to the module, but most of the decision-taking part is done. So, it's not a chaos any more, it's in a very coherent state, but yet it's not everything written in stone. So, if you want to influence somehow in the Money module, this is the moment to get in and participate. The project is in SourceForge (http://sourceforge.net/projects/pymoney), and there we have a mailing list (just to not bloat this one). Thank you. . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
[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 design choices and has an unconventional decomposition of financial functions. * 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. * 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). * The absence of a division operator may prove problematic for allocation routines. * 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 property of some part of the hierarchy of worksheet, row or column, or specific cell. It is not linked to the context for mathematical operations. While the Money module remains experimental, it should remain a third-party package. Raymond
On 7/1/05, Raymond Hettinger
[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/
On Sat, Jul 02, 2005, Facundo Batista wrote:
On 7/1/05, Raymond Hettinger
wrote: * 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.
Sounds like a better way to go is a Money package (or perhaps a Financial package) and just create the Currency module within it for now. Anyway, given that this isn't going to be a real PEP any time soon, please restrict the discussion to comp.lang.python. Thanks for your help keeping python-dev clutter-free. ;-) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
On 7/2/05, Aahz
Sounds like a better way to go is a Money package (or perhaps a Financial package) and just create the Currency module within it for now. Anyway,
Something to consider!
given that this isn't going to be a real PEP any time soon, please restrict the discussion to comp.lang.python. Thanks for your help keeping python-dev clutter-free. ;-)
Well, there's a separate list for the discussions, pymoney-general (accesable through the project in SF). This post was only for tell you people that if you're interested, this is a good moment to jump in. Regards, . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
participants (3)
-
Aahz
-
Facundo Batista
-
Raymond Hettinger