Strange Numeric behavior for failed assignment

Robert Kern kern at myrddin.caltech.edu
Thu Aug 30 00:31:48 CEST 2001


In article <mailman.998458473.11502.python-list at python.org>,
	Chad Netzer <cnetzer at mail.arc.nasa.gov> writes:
> I noticed the following and was wondering if it makes any sense:
> 
> Python 1.5.2 (#0, Apr 10 2001, 10:03:44)  [GCC 2.95.3 20010219 
> (prerelease)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>> from Numeric import *
>>>> a = array((0))
>>>> a
> 0
>>>> a[0]=None
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> TypeError: illegal argument type for built-in operation
>>>> a
> -1
>>>> Numeric.__version__
> '17.1.2'

Bizarre.

Python 1.5.2 (#0, Apr 10 2001, 10:03:44)  [GCC 2.95.3 20010219 (prerelease)] n
linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
o>>> import Numeric
>>> Numeric.__version__ 
'17.3.0'
>>> a = Numeric.array((0))
>>> a
0
>>> a[0] = None
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: illegal argument type for built-in operation
>>> a
-1
>>> 
>>> a.shape
()
>>>  
[myrddin: ~] $ python2
Python 2.0.1 (#0, Jul  3 2001, 12:36:30) 
[GCC 2.95.4 20010629 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import Numeric
>>> a = Numeric.array((0))
>>> a
0
>>> a[0] = None
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: an integer is required
>>> a
-1
>>> Numeric.__version__ 
'20.1.0'

> Should a failed assignment set the assigned value to -1?  It seems to 
> me that the exception should be enough.

Looking at the code for Numeric v20.1.0, it seems that the C functions that
handle the __setitem__'s assign the value of the data pointer to the return
value of the Python API's PyXXX_AsYYY functions. These API functions use a -1 
return value to signify an error. E.g.

  static int INT_setitem(PyObject *op, char *ov) 
  {*((int *)ov)=PyInt_AsLong(op);return PyErr_Occurred() ? -1:0;}

Some rearrangement of the setitem functions could eliminate the risk of 
overwriting data, but it might possibly cost performance.

If you think the behavior should change, post a bug report at Sourceforge and
send a message to numpy-discussion.

http://sourceforge.net/projects/numpy

-- 
Robert Kern
kern at caltech.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



More information about the Python-list mailing list