On Mon, Apr 16, 2012 at 11:29 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Mon, Apr 16, 2012 at 10:09 PM, Ralf Gommers > <ralf.gomm...@googlemail.com> wrote: > > > > > > On Sat, Mar 24, 2012 at 10:13 PM, Charles R Harris > > <charlesr.har...@gmail.com> wrote: > >> > >> Hi All, > >> > >> There several problems with numpy master that need to be fixed before a > >> release can be considered. > >> > >> Datetime on windows with mingw. > > > > Opened http://projects.scipy.org/numpy/ticket/2108 for the last datetime > > failures. > >> > >> Bus error on SPARC, ticket #2076. > >> NA and real/complex views of complex arrays. > >> > >> Number 1 has been proved to be particularly difficult, any help or > >> suggestions for that would be much appreciated. The current work has > been > >> going in pull request 214. > >> > >> This isn't to say that there aren't a ton of other things that need > fixing > >> or that we can skip out on the current stack of pull requests, but I > think > >> it is impossible to consider a release while those three problems are > >> outstanding. > > > > We've closed a number of open issues and merged some PRs, but haven't > made > > much progress on the issues above. Especially for the NA issues I'm not > sure > > what's going on. Is anyone working on this at the moment? If so, can > he/she > > give an update of things to change/fix and an estimate of how long that > will > > take? > > There's been some ongoing behind-the-scenes discussion of the overall > NA problem, but I wouldn't try to give an estimate on the outcome. My > personal opinion is that given you already added the note to the docs > that masked arrays are in a kind of experimental prototype state for > this release, some small inconsistencies in their behaviour shouldn't > be a release blocker. > The release notes already have a whole list of stuff that's > unsupported in the presence of masks ("Fancy > indexing...UFunc.accumulate, UFunc.reduceat...where=...ndarray.argmax, > ndarray.argmin..."), I'm not sure why .real and .imag are blockers and > they aren't :-). Maybe just make a note of them on that list? > > (Unless of course Chuck fixes them before the other blockers are > finished, as per his email that just arrived.) > Good point. If you look at the open tickets for 1.7.0 ( http://projects.scipy.org/numpy/report/3) with a view on getting a release out soon, you could do the following: #2066 : close as fixed. #2078 : regression, should fix. #1578 : important to fix, but not a regression. Include only if fixed on time. #1755 : mark as knownfail. #2025 : document as not working as expected yet. #2047 : fix or postpone. Pearu indicated this will take him a few hours. #2076 : one of many. not a blocker, postpone. #2101 : need to do this. shouldn't cost much time. #2108 : status unclear. likely a blocker. Can someone who knows about datetime give some feedback on #2108? If that's not a blocker, a release within a couple of weeks can be considered. Although not fixing #1578 is questionable, and we need to revisit the LTS release debate... Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
