[Numpy-discussion] Fixing #736 and possible memory leak

Robert Kern robert.kern at gmail.com
Thu Apr 24 19:58:44 EDT 2008


On Thu, Apr 24, 2008 at 5:37 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> Hi,
>
> I've been looking into ticket #736 and playing with some things. In
> arrayobject.c starting at line 8534 I added a check for strings.
>
>         if (PyString_Check(op)) {
>             r = Array_FromPyScalar(op, newtype);
>          }
>         if (PySequence_Check(op)) {
>             PyObject *thiserr = NULL;
>
>             /* necessary but not sufficient */
>             Py_INCREF(newtype);
>             r = Array_FromSequence(op, newtype, flags & FORTRAN,
>                                     min_depth, max_depth);
>             if (r == NULL && (thiserr=PyErr_Occurred())) {
>                 if (PyErr_GivenExceptionMatches(thiserr,
>                                                 PyExc_MemoryError)) {
>                      return NULL;
>                 }
>
> I think there may be a failure to decrement the reference to newtype unless
> Array_FromSequence does that (nasty side effect);
>
> Anyway, the added check for a string fixes the conversion problem for such
> things as int32('123'). There remains a problem with array('123',
> dtype=int32) and with array(['123','123'], dtype=int32), but I think I can
> track those down. The question is, will changing the current behavior so
> that strings get converted to numbers cause problems with other programs out
> there. I suspect I also need to check that strings are converted this way
> only when the type is explicitly given, not detected.

Seems to work for me.

In [5]: array([124, '123', '123'])
Out[5]:
array(['124', '123', '123'],
      dtype='|S4')

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco



More information about the NumPy-Discussion mailing list