Backporting Decimal
People: I don't decide myself what to do in this case. The Decimal module appeared in 2.4, and received just slight modifications for 2.5. Since it appeared, a "just download and use it" version was available for Python 2.3 users. But for 2.6, it was fully renewed. Not only was updated to the last spec from Cawlishaw, but also a lot of (very slightly, arithmetic corner cases) bugs were fixed. Also, it received a lot of code simplifications and speedups. All this is, in most part, because Mark Dickinson was involved here, and he did (and is doing) a great work. When 2.6 is out, I'll update that downloadable for Py2.3. But what to do with Py2.5? Decimal is a pretty stand alone module, and I'm absolutely sure that just backporting the whole module and its testcases will fix a lot of problems, and Py2.5 users will have new functionality, but is this ok? (of course, I can not be 100% sure that any bugs were introduced in these modifications). Recommendations? Thank you very much! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Decimal is a pretty stand alone module, and I'm absolutely sure that just backporting the whole module and its testcases will fix a lot of problems, and Py2.5 users will have new functionality, but is this ok?
Yes! We have guaranteed that spec updates are to be treated as bug fixes and backported. This is especially important in this case because other errors have been fixed and the test cases have grown. Raymond
2007/10/2, Raymond Hettinger <python@rcn.com>:
Yes! We have guaranteed that spec updates are to be treated as bug fixes and backported. This is especially important in this case because other errors have been fixed and the test cases have grown.
Perfect! I'll backport it to 2.5... what about 2.4? Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Yes! We have guaranteed that spec updates are to be treated as bug fixes and backported. This is especially important in this case because other errors have been fixed and the test cases have grown.
Perfect! I'll backport it to 2.5... what about 2.4?
If there are any plans for another 2.4 release, then yes; otherwise, why bother. Raymond
If there are any plans for another 2.4 release, then yes; otherwise, why bother.
Please don't make any functional changes to 2.4. There may be additional releases, but (IMO) they should be security releases only, i.e. contain no functional changes whatsoever (unless they fix a security issue). I'm still trying to work on the PEP that formalizes this notion. Regards, Martin
On 10/2/07, Facundo Batista <facundobatista@gmail.com> wrote:
2007/10/2, Raymond Hettinger <python@rcn.com>:
Yes! We have guaranteed that spec updates are to be treated as bug fixes and backported. This is especially important in this case because other errors have been fixed and the test cases have grown.
Perfect! I'll backport it to 2.5... what about 2.4?
There's one potential breakage that I see here: the Decimal.__pow__ function has different semantics in the new version of Decimal (nonintegers are now allowed as exponents; some previous restrictions on argument sizes no longer exist), so backporting the new version of __pow__ might cause difficulties. In particular, some cases of three-argument pow that previously worked (giving arguably nonsensical results) will now raise an exception. To be honest, I'd be quite surprised to find that *anyone* was using the three-argument pow, but perhaps we should be careful here? Mark
2007/10/2, Mark Dickinson <dickinsm@gmail.com>:
difficulties. In particular, some cases of three-argument pow that previously worked (giving arguably nonsensical results) will now raise an exception. To be honest, I'd be quite surprised to find that *anyone* was
If previously it gave a arguably nonsensical results, and now it raises an exception, I consider it a fixed bug, :) -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
participants (4)
-
"Martin v. Löwis" -
Facundo Batista -
Mark Dickinson -
Raymond Hettinger