Message148650
| Author | vstinner |
|---|---|
| Recipients | brian.curtin, casevh, ced, eric.smith, eric.snow, jjconti, mark.dickinson, rhettinger, skrah, vstinner |
| Date | 2011-11-30.12:40:43 |
| SpamBayes Score | 7.2460644e-08 |
| Marked as misclassified | No |
| Message-id | <1322656844.5.0.664303563845.issue7652@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
> Just to clarify, no decision has yet been made on *whether* > the cdecimal work should be integrated into py3k; > we'll consult python-dev on this once we've got a working branch > and performance information. So, what is the status today? _decimal looks to be huge. Does Python really need yet another multiprecision library? There is already gmpy and bigfloat, based on the heavily optimized GMP library, for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a Decimal API? _decimal should maybe first be distributed as a third party library until it is really well tested and its API is really stable, until we can decide to integrate it. The patch adds __setattr__ to the Decimal class. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2011-11-30 12:40:44 | vstinner | set | recipients: + vstinner, rhettinger, mark.dickinson, casevh, eric.smith, jjconti, ced, brian.curtin, skrah, eric.snow |
| 2011-11-30 12:40:44 | vstinner | set | messageid: <1322656844.5.0.664303563845.issue7652@psf.upfronthosting.co.za> |
| 2011-11-30 12:40:43 | vstinner | link | issue7652 messages |
| 2011-11-30 12:40:43 | vstinner | create | |