> > In Python up to 2.2 it's inconsistent between ints and longs: > > >>> hex(-16711681) > > '0xff00ffff' > > >>> hex(-16711681L) > > '-0xff0001L' # ??!?!? > > The more I think about it, the more I like the suggestion > that was made of representing this as > > 1x00ffff > > which both makes the bit pattern apparent and unambiguously > indicates the sign, all without any assumptions about length. That won't help with %o, %u or %x. I don't expect there will be much of a need to write negative hex constants in practice: people only end up creating negative numbers using hex constants because the want to represent 32-bit bit patterns in a signed 32-bit int. In Python 2.4, the recommended way will be to write 0xffffffff and not worry about the fact that it's a positive long; extensions that take bit masks will be fixed by then to deal with this just fine (probably through the 'k' format code in PyArg_Parse*). The issue of printing negative hex constants is more a theoretical issue: hex(-1) has to return *something*, and 0xffffffff simply isn't acceptable. I'd like it to return something that evaluates back to -1 when used in a Python expression, so "-0x1" and "~0x0" are still the best candidates. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4