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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
