[Python-Dev] Re: buglet in interaction between pygame, Numeric & copy in Python 2.3

Alex Martelli aleaxit@yahoo.com
Thu, 31 Jul 2003 23:14:08 +0200

On Thursday 31 July 2003 09:03 pm, A.M. Kuchling wrote:
> On Thu, 31 Jul 2003 18:06:12 +0200, Alex Martelli <aleaxit@yahoo.com>
> wrote:
> > copy_reg.dispatch_table.  Module
> > Numeric installs such a reductor *WHEN IMPORTED* -- but pygame never
> > imports it even though functions such as the above-used pixels3d do
> > return instances of Numeric.array.
> This is startling; how is it possible to return instances of Numeric.array
> without importing Numeric?

E.g., the way src/surfarray.c does it in pygame (simplifying just a bit):

#include <Numeric/arrayobject.h>

static PyObject* pixels3d(PyObject* self, PyObject* arg)
        PyObject* array;
	array = PyArray_FromDimsAndData(3, dim, PyArray_UBYTE, startpixel);
		((PyArrayObject*)array)->flags = OWN_DIMENSIONS|OWN_STRIDES|SAVESPACE;
... etc, finish initializing the array object
        return array;

The Numeric.array object thus built and returned works well enough (through 
calls to its methods) that the fact that the Numeric module has never been
imported is not apparent to applications using pygame.surfarray.pixels3d and
the like -- except that, _in 2.3_, shallow copying is NOT performed by getting
and calling a method on the object (as it was in 2.2 -- method __copy__) but
rather through a function which must be entered in copy_reg.dispatch_table --
and the task of thus entering said function is performed by Numeric.py's
module body, therefore, performed only if and when the module's imported.

It may be that calling PyArray_FromDimsAndData before Numeric is imported
is considered an error (in this case, I guess pygame should be fixed to avoid
such behavior), but, if so, it's an error that passes _quite_ silently in most 
cases (or used to, up to Python 2.2).  Therefore, it appears to me that some
mention that this error (if such it be) can now (2.3) give problems it would 
not give in 2.2 is warranted in the notes about porting code to 2.3 -- 
Numeric and pygame, being popular extensions, may be given as examples, 
perhaps, but the real issue in terms of the "porting to 2.3" docs seems to me 
to be that such docs DO require a mention about changes in copy.copy's
mechanisms (those changes may require code changes on the part of the
implementor of any copyable type -- Numeric has performed those changes --
AND even extensions just USING such a copyable type may need to change, as I 
think pygame should change in this case [to ensure it imports Numeric if