1.10.3 release tomorrow, 1.11.x branch this month.

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

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

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 < m.h.vankerkwijk@gmail.com> wrote:
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 NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

On Tue, Jan 5, 2016 at 6:17 PM, CJ Carey <perimosocordiae@gmail.com> wrote:
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 < m.h.vankerkwijk@gmail.com> wrote:
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

On Tue, Jan 5, 2016 at 4:55 PM, Marten van Kerkwijk <m.h.vankerkwijk@gmail.com> wrote:
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 :-).
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 -- Nathaniel J. Smith -- http://vorpus.org
participants (4)
-
Charles R Harris
-
CJ Carey
-
Marten van Kerkwijk
-
Nathaniel Smith