[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Mark Dickinson added the comment: Changing title and assignee. (But all help is appreciated: if anyone wants to commit changes to the sandbox directory, please go ahead!) ___ Python tracker __

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Changes by Antoine Pitrou : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Mark Dickinson added the comment: (Adding Raymond to the nosy list.) In r68494, I've checked in some work towards rewriting Decimal (or parts of Decimal) in C. I reused Facundo's old /decimal directory in the sandbox, so the URL is: http://svn.python.org/view/sandbox/trunk/decimal/decimal_i

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Just a quick note to say I am still working on this. I'll post some new code soon. ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > So I would suggest either a new directory in the sandbox, or re-using > Facundo's original directory (which includes the telco benchmark) Makes sense---thanks for the suggestion! But since it seems I don't have any open ssh ports it looks

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Facundo Batista <[EMAIL PROTECTED]> added the comment: Nick said: > So I would suggest either a new directory in the sandbox, or > re-using Facundo's original directory (which includes the > telco benchmark) +1 > And I agree that it is far more sensible to target 2.7/3.1 at > this stage -

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Nick Coghlan <[EMAIL PROTECTED]> added the comment: This is the kind of project where the sandbox is useful - Facundo's original decimal work was done there, as was the attempt at a complete rewrite of the decimal module in C (which turned out to be a less than optimal approach to the speed probl

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Sorry for the silence: new country + new job + no internet connection outside work = not many opportunities to spend time on this (or any other part of Python) at the moment. I do now have a version 0.2 of the deccoeff type, and more impor

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Facundo Batista <[EMAIL PROTECTED]> added the comment: Can not get into this now, but I'll be able to deal with this in some weeks... -- assignee: -> facundobatista ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Looks like we'll be living with the slowdown for 3.0, so marking this as a high priority item for 3.1. (Given that the API doesn't change, I wonder if this could be included in a 3.0.1 release?) -- priority: -> high versions: +Python

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Facundo Batista <[EMAIL PROTECTED]> added the comment: I like this path, also. Beyond Deccoeff, this module could hold in the future other functions that are speed critical. Great work, Mark! __ Tracker <[EMAIL PROTECTED]>

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

Nick Coghlan <[EMAIL PROTECTED]> added the comment: (I changed the issue title to better reflect where the discussion has moved to) I really like the approach of a custom internal type for the mantissa storage (the module containing would probably best be called _decimal). Then it should be poss