[Joshua Luben]
> I thought I would post this here first before seeking more experienced ears
> for this particular strangness.
>
> I have Python 2.4.2 installed from source on a dual processor dell server.
> These are x86_64 processors (verified by /bin/arch) (aka emt64 extensions).
>
> uname -a gives
> Linux eps-linuxserv3 2.6.5-7.244-smp #1 SMP Mon Dec 12 18:32:25 UTC 2005
> x86_64 x86_64 x86_64 GNU/Linux
>
> The flavor of Linux is 64 bit SUSE SLES 9 with the latest updates.
>
>
> Now for the strangeness. I'm using DCOracle2 (can't use anything else, as
> this is the corporate standard) also compiled from source. When calling
> executemany() when any parameter is of type int, I get a OverflowError. I
> turned on debug traces in DCOracle2; this indicated that PyArg_ParseTuple()
> was returning sizeof(int) = 4 bytes.
Sounds right to me. I don't know of any platform other than old Cray
Research boxes where sizeof(int) > 4.
> DCOracle2 is compiled such that sizeof(int) = 8 bytes.
Sounds wrong to me.
> Python itself gives,
>
> python -c "import sys; print sys.maxint"
> 9223372036854775807
>
> Therefore, indicating that the size of int is 8 bytes.
No, it does not. A Python `int` is a C `long`, and sizeof(long) = 8
on most 64-bit boxes (Win64 is an exception). The size of a platform
C long can be deduced from the value of Python's sys.maxint, but
nothing about the size of a platform C int.
> So I'll go out on a limb here and assume that this is a python problem...but
> I don't know where to take it...
I'd start with this part, which sounds crazy:
DCOracle2 is compiled such that sizeof(int) = 8 bytes.
--
http://mail.python.org/mailman/listinfo/python-list
