Facundo Batista wrote:
2007/11/24, Nick Coghlan [EMAIL PROTECTED]:
Did you change the Decimal repr to use the same format for the mantissa?
I don't understand the question. The output of repr() does not show
this internals...
Yeah, um... can we just forget I asked that question? (I blame
2007/11/24, Nick Coghlan [EMAIL PROTECTED]:
Did you change the Decimal repr to use the same format for the mantissa?
I don't understand the question. The output of repr() does not show
this internals...
Could you also check the performance gain against the telco benchmark
which is in the
Facundo Batista wrote:
Mark Dickinson found out that a lot of time was lost internally in
decimal.py when dealing with the Decimal mantissas.
He changed the way that mantissa was stored, from a tuple of ints, to
a plain string (each character a digit). This achieved a speedup of
around a
On 9/28/07, Thomas Heller [EMAIL PROTECTED] wrote:
Thomas Wouters schrieb:
If you re-eally need to check something into the trunk that re-eally
must not be merged into py3k, but you're afraid it's not going to be
obvious to the merger, please record the change as 'merged' using
If the differences are few, I prefer that you insert some conditionals
that attach different functions based on the version number. That way
we can keep a single version of the source that works on all of the
pythons.
Raymond
On Sep 29, 2007, at 8:26 AM, Thomas Wouters [EMAIL PROTECTED]
Thomas Wouters schrieb:
On 9/27/07, Eric Smith [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
Unfortunately, that's not how it works :-) If you check something into
the trunk, it will be merged into Py3k sooner or later. I may ask the
original submitter for assistance if it's incredibly
Thomas Wouters wrote:
Unfortunately, that's not how it works :-) If you check something into
the trunk, it will be merged into Py3k sooner or later. I may ask the
original submitter for assistance if it's incredibly hard to figure out
the changes, but so far, I only had to do that with the
On 9/27/07, Eric Smith [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
Unfortunately, that's not how it works :-) If you check something into
the trunk, it will be merged into Py3k sooner or later. I may ask the
original submitter for assistance if it's incredibly hard to figure out
the
2007/9/18, Thomas Wouters [EMAIL PROTECTED]:
Unfortunately, that's not how it works :-) If you check something into the
trunk, it will be merged into Py3k sooner or later. I may ask the original
submitter for assistance if it's incredibly hard to figure out the changes,
but so far, I only had
On 9/19/07, Facundo Batista [EMAIL PROTECTED] wrote:
2007/9/18, Thomas Wouters [EMAIL PROTECTED]:
Unfortunately, that's not how it works :-) If you check something into
the
trunk, it will be merged into Py3k sooner or later. I may ask the
original
submitter for assistance if it's
2007/9/19, Thomas Wouters [EMAIL PROTECTED]:
So, how is this handled? Until which moment can I expect that the
changes in the trunk are merged to Py3k?
Until you hear otherwise :) You can commit py3k-specific changes to the py3k
branch, the merges shouldn't lose them. (Of course, mistakes
On 9/13/07, Facundo Batista [EMAIL PROTECTED] wrote:
Hi people!
After some months, Decimal is now in the trunk again.
It's fully updated to the latest Cowlishaw specification, and
complying with the latest test cases (from a few days ago, which even
take in consideration some feedback from
Hi people!
After some months, Decimal is now in the trunk again.
It's fully updated to the latest Cowlishaw specification, and
complying with the latest test cases (from a few days ago, which even
take in consideration some feedback from ours).
I want to thank so much to Mark Dickinson, who
13 matches
Mail list logo
