On Fri, 03 Feb 2006 19:56:20 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
>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. Ok, I'll take your word that 'k' coercion takes no significant time for longs vs ints. I thought there might be a case in a hot loop where it could make a difference. I confess not having done a C extension since I wrote one to access RDTSC quite some time ago. > >> 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. Well, I was visualizing having a homogeneous bunch of bit mask definitions all as int type if they could fit. I can't express them all in hex as literals without some processing. That got me started ;-) Not that some one-time processing at module import time is a big deal. Just that it struck me as a wart not to be able to do it without processing, even if constant folding is on the way. > >>>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. Ok, well that's the provision for the coercion then. BTW, is long mandatory for all implementations? Is there a doc that defines minimum features for a conforming Python implementation? E.g., IIRC Scheme has a list naming what's optional and not. Regards, Bengt Richter _______________________________________________ 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
