[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