On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I thought that might be what happened, but I couldn't remember if that > optimisation was a 2.6 only change or not (I suspect it was included in > 2.5 as a prereq to the spec compliance updates). > Exactly. > Anyway, +1 on coercing the mantissa to a str() instance in 2.5. > > This does raise an interesting point though - currently Decimal in Py3k > is storing the mantissa as a Unicode instance instead of a bytes > instance. The performance implications of that are horrendous since > PyLong_FromUnicode does a malloc, encodes the string into the malloced > buffer, then invokes PyLong_FromString on the result. > Urk! Yes, this definitely needs to be looked at. > The following is also a problem in Py3k: > [...] > > The isinstance(value, str) check in Py3k is too restrictive - it needs > to accept bytes instances as well. > I don't understand this. Why does Decimal.__new__ need to accept bytes instances? Isn't it just supposed to be creating a Decimal from a string? Or is the idea that it should accept ASCII strings that are masquerading as bytes instances, for reasons of convenience/efficiency/something else? Unicode/bytes/str and encoding issues frighten me much more than floating-point arithmetic ever did, so I expect I'm missing many things here. Mark
_______________________________________________ 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