proposed language change to int/int==float (was: PEP0238 lament)

[David Bolen]

Robin Becker <robin at jessikat.fsnet.co.uk> writes:

> well I have at least one extension that requires 32 bit unsigned as
> inputs. Under existing python I can manipulate myself around bit 31
> problems with ease (using negative numbers or hex). It seems it
> will/might be a bit more complicated if this pep goes through. I'm sure
> there are others who have explicit int size requirements. Effectively
> removing ints takes away ease of external communication in at least some
> cases.

If implemented cleanly, it may even make live easier for your
extension, depending on how its functions process input, since they'll
all still come in as PyObject's.

For example, if your extension uses PyArg_ParseTuple to convert to the
Python value to your internal 32 bit unsigned storage, it'll probably
still continue to do so, automatically taking into account any
unification within the Python core.  In fact one could imagine the "l"
format (which presumably you're using now since 'int' wouldn't be a
portable ubit32 format in your C extension) would automatically handle
all of integers, longs, or integral floats behind the scenes.  You'd
then do a final sanity check to ensure the value was within 32-bits,
but presumably you do that now as well.  If, instead, you're using "i"
today and just giving it a pointer to an 'unsigned int' variable,
you're already being a bit risky in your extension coding, but that
should presumably continue to work as well, and presumably Python
would complain when trying to convert a number that wouldn't fit into
the platform 'int'.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/