Jack Jansen wrote: > As of recently I'm getting deprecation warnings on lots of constructs of > the form "0xff << 24", telling me that in Python 2.4 this will return a > long. Interesting. I wonder why the implementation warns about 0xff << 24... 0xff000000 fits nicely into a 32-bit integer. I don't see why the "changing sign" is relevant here or even why it is mentioned in the warning since the PEP doesn't say anything about it. Changing these semantics would cause compatibility problems for applications doing low-level bit manipulations or ones which use the Python integer type to store unsigned integer values, e.g. for use as bitmapped flags. > As these things are bitpatterns (they're all generated from .h files for > system call interfaces and such) that the user will pass to methods that > wrap underlying API calls I don't want them to be longs. How do I force > them to remain ints? -- 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