There are porting hints and a patch for pygtk at http://www.scipy.org/Porting_to_NumPy

Dropping numeric support is definately needed, since numeric is broken on amd64 with Python 2.5. Gentoo Linux is dropping numeric support and trying to port or remove (which, of course, is not an option with pygtk) all packages depending on it. You can expect more distros following this path in the future.

Agreed... there's no point to support a deprecated library so pygtk should migrate to numpy or develop a specific library for pygtk.

Can this go upstream?

FYI I'm coding a tricky workaround for this bug in my application. Please?

Ping, what's the status on this? There's a patch in Gentoo's bugzilla, can it be reviewed?

https://bugs.gentoo.org/attachment.cgi?id=125297&action=view

Thanks

(In reply to comment #5)
> Ping, what's the status on this? There's a patch in Gentoo's bugzilla, can it
> be reviewed?
> 
> https://bugs.gentoo.org/attachment.cgi?id=125297&action=view

Can you attach that patch to this bugzilla, please?

Created attachment 111653 [details] [review]
patch to replace Numeric with numpy

Here's the patch. Disclaimer, I'm just forwarding the patch written by fellow gentoo dev Ali Polatel.

(In reply to comment #7)
> Created an attachment (id=111653) [edit]
> patch to replace Numeric with numpy
> 
> Here's the patch. Disclaimer, I'm just forwarding the patch written by fellow
> gentoo dev Ali Polatel.
> 

I think this patch looks good, I'm slightly concerned that switching from Numeric to numpy in one go will not provide a smooth migration though.
I'd rather support both during a transition period, can I patch be provided for that?

(In reply to comment #8)
> I think this patch looks good, I'm slightly concerned that switching from
> Numeric to numpy in one go will not provide a smooth migration though.
> I'd rather support both during a transition period, can I patch be provided for
> that?

Our resident python expert (who wrote the patch) tells me that Numeric is dead and hasn't been updated in over a year. From the numpy homepage :

"Maintenance has ceased for Numeric, and users should transisition to NumPy as quickly as possible."

But of course, it's your call :)

> Our resident python expert (who wrote the patch) tells me that Numeric is dead
> and hasn't been updated in over a year. From the numpy homepage :
>
> "Maintenance has ceased for Numeric, and users should transisition to NumPy as
> quickly as possible."

That I do not question, I believe you that it is dead.
However, lots of people do have Numeric installed on their machines, most pygtk packages for Linux distributions depends on Numeric, so thus they have it installed. Applications using PyGTK & Numeric together will break, which is not acceptable.

What I think is reasonable is:
- Add conditional support for Numpy in PyGTK
- Deprecate Numeric support

wait a couple of releases

- Remove Numeric support

I just don't want to do all these three items in the same release for the reasons mentioned above

Then maybe this needs to be coordinated with other gnome/python packages so that it all happens at the same time. Could it be done and tested in time for Gnome 2.24 and then completely removed for 2.26 ? Maybe it could all be done for 2.24 ?

Thanks

No, it cannot be done just for 2.24. It's not just about GNOME, there are other applications apart from GNOME using PyGTK. 

From PyGTK point of view gnome/python applications are no different from any others, they need all need to be updated.

IMHO I think it should not be too bad to just migrate to numpy for the next pygtk _major_ release.  Just don't do it in a bugfix release, that would be bad karma :-/

Of course I agree with Johan, a transition phase where both numpy numeric would be accepted (giving precedence to numpy) would be ideal, but it does require more work.  Conditional compiling is never easy to code... :P

Ping: Is a transition to numpy in the cards for pygtk 2.13?

Asking because the OLPC guys are clamoring for this:
http://bugzilla.redhat.com/show_bug.cgi?id=459822

For the record, this is my current workaround. It's a swiged c++ header which creates a numpy wrapper around the old numeric data:

http://svn.gna.org/viewcvs/mypaint/trunk/lib/gdkpixbuf2numpy.hpp?rev=90&view=auto

Any update on this? The last release of numeric was over 3 years ago. There's also patches for a number of things that use(d) numeric including pygtk that's on the link in comment #1

For what it's worth, Debian has a patched version in experimental that uses Numpy instead of Numeric:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478452

(In reply to comment #17)
> For what it's worth, Debian has a patched version in experimental that uses
> Numpy

The patch can be found in our patch tracking system, but you’ll see it’s almost the same as the one from Gentoo.

Is there a status update on this? Is it due to be fixed in time for gnome 2.26?

If we can have a patch that applies cleanly against trunk I will push it for 2.15/2.16. We now have to close this one.

Created attachment 128739 [details] [review]
Patch updated against svn trunk

Here you go.

Sorry but if numpy isn't found:

checking for GDK target... x11
Traceback (most recent call last):

+ Trace 212568

checking for numpy/arrayobject.h... no

Everything will be broken:

atk.c:16911: error: ‘ATK_TYPE_STATE_SET’ undeclared (first use in this function)
atk.c:16913: error: ‘ATK_TYPE_UTIL’ undeclared (first use in this function)
make[2]: *** [atk_la-atk.lo] Error 1
make[2]: Leaving directory `/home/gianmt/Repos/pygtk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/gianmt/Repos/pygtk'
make: *** [all] Error 2

Created attachment 128767 [details] [review]
Patch for SVN trunk that works when numpy is not here

Here is another attempt (and this time, I also tried without numpy installed).

Josselin thanks for the updates patch, it applies and works correctly in both cases, with and without numpy.

I didn't investigate at all this warning:

gdkpixbuf.override: In function ‘have_numpy’:
gdkpixbuf.override:78: warning: ‘return’ with no value, in function returning non-void

I guess something is changed in the numpy init function?

Is there any progress in getting this merged?

It's ready to be merged, but I have no time to look at that warning, help appreciated.

The problem is that "import_array" is a macro which calls return.  The 
"have_numpy" function returns a value, so this causes a problem.

Replacing the line in gdkpixbuf.override so that "is_array();" is changed
to "is_array1(1);" fixes the problem.

Note from the numpy code, is_array1 allows you to return a value you specify
on error.  You can also specify a message to display if you use import_array2.
Here is the #defines from the NumPy code:

./code_generators/generate_numpy_api.py:
#define import_array() {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, "numpy.core.multiarray failed to import"); return; } }
#define import_array1(ret) {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, "numpy.core.multiarray failed to import"); return ret; } }
#define import_array2(msg, ret) {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, msg); return ret; } }

So this should be an easy fix if you want to get rid of the warning.

Created attachment 132211 [details] [review]
patch to address warning


Attached patch deals with the warning.  It affects a file not in the previous patch.

This is great. Thanks every one. What release will this hit, and is it scheduled yet?

(In reply to comment #29)
> This is great. Thanks every one. What release will this hit, and is it
> scheduled yet?
> 

I plan in a few days to release pygtk-2.15.0 since I've already added GTK+ 2.16 API to trunk.