Mailing List Archive: Long integers getting short shrift?

Long integers getting short shrift?

Apr 27, 1999, 1:52 PM

Post #1 of 3 (436 views)

The functions Py_BuildValue and PyArg_ParseTuple don't seem to be
listed in the index of the Python/C API documentation. They are only
described in the Embedding and Extending docs.

The "L" format code for Long integers is not described anywhere,
AFAICT. I discovered it by reading source.

It seems that if you are on a system without the "long long" type then
the "L" format char is not available. The "L" format performs the
same function as the "PyLong_FromLongLong" function, but there's no
format character to get me the equivalent of "PyLong_FromLong". So,
if I am calling a Python function from C which is expecting a long int
as an arg, I am forced to write

result = PyObject_CallFunction(func, "O", PyLong_FromLong(x));

which isn't terrible but isn't as nice as writing

result = PyObject_CallFunction(func, "L", x);

which I can only do if the system has "long long" and x is of that
type... I'd like to be able to get regular C integers into Python
long's.

One reason for wanting this is that I often use long's in Python to
hold what would be in C an "unsigned int" - since there's no
"unsigned" type in Python, to represent a 32-bit value without
sign-bit I use a Python long.

Long integers getting short shrift? [ In reply to ]

ivanlan at callware

Apr 27, 1999, 2:42 PM

Post #2 of 3 (453 views)

Permalink

Hi All--

Charles G Waldman wrote:
>
> The functions Py_BuildValue and PyArg_ParseTuple don't seem to be
> listed in the index of the Python/C API documentation. They are only
> described in the Embedding and Extending docs.
>
> The "L" format code for Long integers is not described anywhere,
> AFAICT. I discovered it by reading source.
>
> It seems that if you are on a system without the "long long" type then
> the "L" format char is not available.

???? I have Python running on my UnixWare system at home, and the long
types are easily accessible. Python's been running on it since 1.3, and
UnixWare has no long long type. Long doubles, but no long long. (By
the way, the UnixWare system is going to die on 10 May, when Redhat 6.0
with 2.2 kernel and SMP out of the box appears in the stores.)

Now, possibly this is a difference between the running interpreter and
the functions available for building extensions, but if so, why the
difference?

<always-in-search-of-enlightenment>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
ivanlan@callware.com
http://www.pauahtun.org
See also:
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
----------------------------------------------

Long integers getting short shrift? [ In reply to ]

cgw at fnal

Apr 27, 1999, 4:13 PM

Post #3 of 3 (425 views)

Permalink

Ivan Van Laningham writes:

> ???? I have Python running on my UnixWare system at home, and the long
> types are easily accessible.

Perhaps I was unclear, I'm not saying that the long type is not
available; I'm referring to the level of support for Long objects in
the Python/C API, in particular the functions PyArg_ParseTuple and
PyObject_CallFunction. Below is the snippet of code in getargs.c that
handles the "L" format character... I was wishing for something
similar to "L" that would take a plain C int and make a Python Long
out of it... I don't know what letter I'd use since l and L are
already taken!

It's not too important, one can always use the "O" format letter and
handle the arg. specially with PyLong_FromLong; it's just a bit ugly
to have to do so.

#ifdef HAVE_LONG_LONG
case 'L': /* LONG_LONG */
{
LONG_LONG *p = va_arg( *p_va, LONG_LONG * );
LONG_LONG ival = PyLong_AsLongLong( arg );
if( ival == (LONG_LONG)-1 && PyErr_Occurred() ) {
return "long<L>";
} else {
*p = ival;
}
break;
}
#endif