Guido van Rossum wrote: >>Guido van Rossum <guido@python.org> writes: >> >> >>>There's no excuse for that any more. The 'i' and 'l' format chars of >>>PyArg_Parse* and PyInt_AsLong() both work for longs as well as for >>>ints. Sigh. > Martin: > >>There is a change, of course: Passing 0xff<<24 to a function that uses >>the "i" converter will produce an OverflowError, whereas it previously >>would pass in the negative numbers. > > > And unfortunately the same will happen for the "l" converter > (PyInt_AsLong(<long>) does a signed range check. > > >>For cases of "I want 32 bits in an int", you'll have to accept both >>signed and unsigned 32 bits - something that is currently not >>supported in ParseTuple. > > > 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). Rather than inventing something new to be compatible to the existing old status quo, I'd rather like to see new format codes for unsigned integers and/or longs and have the existing ones support the new status quo. > 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(). > > Any takers? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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