On Tue, 2009-08-11 at 07:12 -0500, Jon Ciesla wrote:
> Adam Jackson wrote:
> > On Mon, 2009-08-10 at 14:40 -0500, Jon Ciesla wrote:
> >> Since pygtk2 does actually use numpy, isn't d) the best (albeit most
> >> annoying) option?
> >
> > Internally? Or just to implement that one entrypoint? I believe it to
> > be the latter.
Having double-checked: it's just to implement get_pixels_array().
> I'm not sure, but what practical difference would that make?
Well, it's a soft dep...
If built with numpy support, get_pixels_array() starts off with:
if (!have_numpy())
return NULL;
The important bit of have_numpy() looks like:
static int import_done = 0;
if (!import_done()) {
import_done = 1;
import_array1(1);
if (PyErr_Occurred()) {
/* throw */
}
}
import_array1() is a small wrapper around _import_array(), which starts
off with:
PyObject *numpy = PyImport_ImportModule("numpy.core.multiarray");
if (numpy == NULL) return -1;
And it turns out this is all static inlines that get built straight into
pygtk2 itself. In other words, if this bit of pygtk2 were written in
python, it'd look like:
class gdk:
def get_pixels_array(self):
import numpy.core.multiarray
# do a bunch of stuff
and if that python module weren't available it'd just throw an
exception.
So: python apps that call get_pixels_array() can Requires: numpy
themselves, and then that entrypoint will work. Python apps that
_don't_, need not, and then numpy and its deps go missing, but it
doesn't matter because you never call get_pixels_array() so the
exception never happens.
So I think my b) suggestion (of replicating the ABI in pygtk2) is
actually redundant, it's what's already happening. pygtk2 already knows
the object layout of numpy arrays thanks to #includes of doom, it just
doesn't try to create them unless the rest of the numpy exists.
The question is only whether to keep the 'Requires: numpy' in pygtk2 or
to push it out to apps that use get_pixels_array(). And I think the
latter sounds just fine to me.
- ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
