From 9940b800a497463fb4c1144c3738cfcec41cdaea Mon Sep 17 00:00:00 2001 From: Tim Peters Date: Fri, 1 Dec 2000 07:59:35 +0000 Subject: Made the description of %[udxXo] formats of negative longs in 2.1 more accurate. I suggested to Guido that %u be deprecated (it seems useless in Python to me). --- Misc/NEWS | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS index 14ba867..ed29fcb 100644 --- a/Misc/NEWS +++ b/Misc/NEWS @@ -3,7 +3,7 @@ What's New in Python 2.1 alpha 1? Core language, builtins, and interpreter -- %[duxXo] formats of negative Python longs now produce a sign +- %[xXo] formats of negative Python longs now produce a sign character. In 1.6 and earlier, they never produced a sign, and raised an error if the value of the long was too large to fit in a Python int. In 2.0, they produced a sign if and @@ -12,11 +12,21 @@ Core language, builtins, and interpreter platforms), and inconsistent with hex() and oct(). Example: >>> "%x" % -0x42L - '-42' # in 2.1 + '-42' # in 2.1 'ffffffbe' # in 2.0 and before, on 32-bit machines >>> hex(-0x42L) '-0x42L' # in all versions of Python + The behavior of %d formats for negative Python longs remains + the same as in 2.0 (although in 1.6 and before, they raised + an error if the long didn't fit in a Python int). + + %u formats don't make sense for Python longs, but are allowed + and treated the same as %d in 2.1. In 2.0, a negative long + formatted via %u produced a sign if and only if too large to + fit in an int. In 1.6 and earlier, a negative long formatted + via %u raised an error if it was too big to fit in an int. + What's New in Python 2.0? ========================= -- cgit v0.12