[Numpy-discussion] 1.10.3 release tomorrow, 1.11.x branch this month.

[Charles R Harris]

Hi All,

I'm going to attempt a 1.10.3 release tomorrow to address the segfault
reported in #6922 <https://github.com/numpy/numpy/issues/6922>.

I'd also like to branch 1.11.x sometime this month, hopefully around Jan 18
(two weeks from now). There are some unresolved issues, in particular
__numpy_ufunc__, but there is plenty of accumulated material and I'd like
to get something out before the tinder buildup constitutes a fire hazard.
Releases generate plenty of sparks and it would be good if the 1.11.0
release was less flamable than the 1.10 release was. I will take a look
through the current bug fix PRs with intent to merge as many as possible
before the branch, but enhancements will not be a high priority except for
a couple that have been sitting ready in the queue for awhile. If there are
some enhancements that you think need to be in the release, mention them
here.

Chuck

[Marten van Kerkwijk]

Hi Chuck, others,

A propos __numpy_ufunc__, what is the current status? Is it still the
undetermined result of the monster-thread (
https://github.com/numpy/numpy/issues/5844 -- just found it again by
sorting by number of comments...)?

As noted by Stephan and myself when the decision was made to remove it from
1.10, for external libraries it would be really wonderful to have *any*
version of __numpy_ufunc__ in 1.11, as it provides great beneifts (instant
factor 2 improvement in speed for astropy quantities...). In the end, the
proposals were not that different, and, really, what is in current master
is quite good.

All the best,

Marten

[CJ Carey]

I'll echo Marten's sentiments. I've found __numpy_ufunc__ as it exists in
the master branch to be quite useful in my experiments with sparse arrays (
https://github.com/perimosocordiae/sparray), and I think it'll be a net
benefit to scipy.sparse as well (despite the unpleasantness with __mul__).

-CJ

On Tue, Jan 5, 2016 at 6:55 PM, Marten van Kerkwijk <

Post by Marten van Kerkwijk
Hi Chuck, others,
A propos __numpy_ufunc__, what is the current status? Is it still the
undetermined result of the monster-thread (
https://github.com/numpy/numpy/issues/5844 -- just found it again by
sorting by number of comments...)?
As noted by Stephan and myself when the decision was made to remove it
from 1.10, for external libraries it would be really wonderful to have
*any* version of __numpy_ufunc__ in 1.11, as it provides great beneifts
(instant factor 2 improvement in speed for astropy quantities...). In the
end, the proposals were not that different, and, really, what is in current
master is quite good.
All the best,
Marten
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Charles R Harris]

Post by CJ Carey
I'll echo Marten's sentiments. I've found __numpy_ufunc__ as it exists in
the master branch to be quite useful in my experiments with sparse arrays (
https://github.com/perimosocordiae/sparray), and I think it'll be a net
benefit to scipy.sparse as well (despite the unpleasantness with __mul__).
-CJ
On Tue, Jan 5, 2016 at 6:55 PM, Marten van Kerkwijk <

Post by Marten van Kerkwijk
Hi Chuck, others,
A propos __numpy_ufunc__, what is the current status? Is it still the
undetermined result of the monster-thread (
https://github.com/numpy/numpy/issues/5844 -- just found it again by
sorting by number of comments...)?
As noted by Stephan and myself when the decision was made to remove it
from 1.10, for external libraries it would be really wonderful to have
*any* version of __numpy_ufunc__ in 1.11, as it provides great beneifts
(instant factor 2 improvement in speed for astropy quantities...). In the
end, the proposals were not that different, and, really, what is in current
master is quite good.
All the best,

Well, I'm trying to gin up some action on the topic ;) The last time I
brought it up it vanished into the mists. I don't think it would be a lot
of work to finish things up and have comtemplated doing it myself if no one
else steps up. I want to make the 1.11 branch this month whatever happens.

Chuck

[Nathaniel Smith]

On Tue, Jan 5, 2016 at 4:55 PM, Marten van Kerkwijk

Post by Marten van Kerkwijk
Hi Chuck, others,
A propos __numpy_ufunc__, what is the current status? Is it still the
undetermined result of the monster-thread
(https://github.com/numpy/numpy/issues/5844 -- just found it again by
sorting by number of comments...)?

Yeah, that's about where everyone collapsed in exhaustion last time :-).

Post by Marten van Kerkwijk
As noted by Stephan and myself when the decision was made to remove it from
1.10, for external libraries it would be really wonderful to have *any*
version of __numpy_ufunc__ in 1.11, as it provides great beneifts (instant
factor 2 improvement in speed for astropy quantities...). In the end, the
proposals were not that different, and, really, what is in current master is
quite good.

I think everyone's agreed that having __numpy_ufunc__ is a great
thing; the problem is sorting out the details, which is work that
takes some time and attention.

At this point I think it's extremely unlikely that that time and
attention will be mustered in time for 1.11, just because like Chuck
says, that's 2 weeks from now, and none of us have magic wands to get
the work done. We could potentially get it into 1.11 by pushing the
release back, but that wouldn't really help anything: it wouldn't make
the work happen any sooner by the calendar; it would just delay
releasing all the other stuff that's in master.

I've also been feeling frustrated and guilty about the status of
__numpy_ufunc__; I very much want to get back to it, but have been too
far underwater from other commitments :-(.

One possible next step, if someone does have the
time/energy/motivation, would be to review the outcome of that thread
and write up a short summary of where we got to. Basically cutting out
all the back-and-forth and dead-ends to say "here are the 2-3 main
options that are still on the table, here are the details of the best
version of each, here are the trade-offs".

-n