On Tue, 13 Aug 2002, Guido van Rossum wrote: >> >> If we switch to "k" for integers in the range -2**-31..2**31-1 that >> >> would not be too much work, as a lot of the code is generated (I would >> >> take the quick and dirty approach of using k for all my integers). Only >> >> the hand-written code would have to be massaged by hand. >> > >> > Glad, that's my preferred choice too. But note that in Python 2.4 and >> > beyond, 'k' will only accept positive inputs, so you'll really have to >> > find a way to mark your signed integer arguments up differently. >> >> Huh??! Now you've confused me. If "k" means "32 bit mask", why would it >> be changed in 2.4 not to accept negative values? "-1" is a perfectly >> normal way to specify "0xffffffff" in C usage... > >Hm, in Python I'd hope that people would write 0xffffffff if they want >32 one bits -- -1L has an infinite number of one bits, and on 64-bit >systems, -1 has 64 one-bits instead of 32. Most masks are formed by >taking a small positive constant (e.g. 1 or 0xff) and shifting it >left. In Python 2.4 that will always return a positive value. > >But if you really don't like this, we could do something different -- >'k' could simply give you the lower 32 bits of the value. (Or the >lower sizeof(long)*8 bits???). For a mask, it makes some kind of sense to require all the high bits, those not ports of the mask, to be all the same; it makes it less likely that something important gets lost when they're trimmed off. But, don't all ones make just as much sense as all zeros ? Even with unified numbers, -1 (or ~0) seems to be a reasonable way to spell a bitmask with all bits set, without having to know how many "all" are. /Paul
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