diff options
author | Tim Peters <tim.peters@gmail.com> | 2000-12-01 07:59:35 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2000-12-01 07:59:35 (GMT) |
commit | 9940b800a497463fb4c1144c3738cfcec41cdaea (patch) | |
tree | 92a5f5e4cfbfd24f7d6cac0b6d9c2e66ea0edc9c | |
parent | 5725d1eb034193e521dfe5febd675fb84e6acf5d (diff) | |
download | cpython-9940b800a497463fb4c1144c3738cfcec41cdaea.zip cpython-9940b800a497463fb4c1144c3738cfcec41cdaea.tar.gz cpython-9940b800a497463fb4c1144c3738cfcec41cdaea.tar.bz2 |
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).
-rw-r--r-- | Misc/NEWS | 14 |
1 files changed, 12 insertions, 2 deletions
@@ -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? ========================= |