On maandag, augustus 12, 2002, at 05:37 , Guido van Rossum wrote: > Oops. Darn. You're right. Sigh. That's painful. We have to add a > new format code (or more) to accept signed 32-bit ints but also longs > in range(32). This should be added in 2.3 so extensions can start > using it now, and user code can start passing longs in range(2**32) > now. I propose 'k' (for masK). We should backport this to 2.2.2 as > well. Plus a variant on PyInt_AsLong() with the same semantics, maybe > named PyInt_AsMask(). Ow, pleeeeeeeeeeeeeeeeeeeeeeeeaaaaaase........ Just before 2.1 was released (or was it 2.0?) on a whim someone "fixed" the short integer handling to bother about signs, in a backward-incompatible way, despite that fact that about 95% of the short PyArg_Parse formats in the core were mine, and I asked for some form of backward compatibility. I spent about 2 weeks going over a few thousand API calls to fix this mess at a time I had more than enough other work on my hands. Can we please make this change in a backwards-compatible way, i.e. leave the i and l formats alone and use something new for "range-checked-int" and "range-checked-long"? I already fear that I have to come up with some sort of a fix for the range-check warning (more than 6000 lines worth of constant definitions that can currently be copied verbatim from C header files to Python will have to be parsed, and computed, and all these things can contain references to other constants, strings and who knows what more, see Mac/Lib/Carbon/*.py), I really could do without more work on my plate... -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
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