Bengt Richter wrote: > If you are looking at them in C code receiving them as args in a call, > "treat them the same" would have to mean provide code to coerce long->int > or reject it with an exception, IWT. The typical way of processing incoming ints in C is through PyArg_ParseTuple, which already has the code to coerce long->int (which in turn may raise an exception for a range violation). So for typical C code, 0x80000004 is a perfect bit mask in Python 2.4. > It's not a matter of "buggy" if you are trying to optimize. > (I am aware of premature optimization issues, and IMO "strange" > is in the eye of the beholder. What syntax would you suggest? The question is: what is the problem you are trying to solve? If it is "bit masks", then consider the problem solved already. >>Same goes for code that says it takes a 32-bit bitfield argument but >>won't accept 0x80000000. > > If the bitfield is signed, it can't, unless you are glossing over > an assumed coercion rule. Just have a look at the 'k' specifier in PyArg_ParseTuple. Regards, Martin
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