<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I thought it was clear we were doing a 1.7 release before SciPy. It seems pretty urgent that we get something out sooner than later. I know there is never enough time to do all the things we want to do. <div><br></div><div>There is time before the first Release candidate to make changes on the 1.7.x branch. If you want to make the changes on master, and just indicate the Pull requests, Ondrej can make sure they are added to the 1.7.x. branch by Monday. We can also delay the first Release Candidate by a few days to next Wednesday and then bump everything 3 days if that will help. There will be a follow-on 1.8 release before the end of the year --- so there is time to make changes for that release as well. The next release will not take a year to get out, so we shouldn't feel pressured to get *everything* in this release. </div><div><br></div><div><br></div><div>Speaking of code changes...</div><div><br></div><div>What are the cleanups for macros that need to be done? I was looking at the code and notice that where before I could do PyArray_NDIM(obj), Mark's code now does PyArray_NDIM((PyArrayObject *)obj). Is that intentional? That's not as nice to type. Is that assuming that PyArray_NDIM will become a function and need a specific object type for its argument (and everything else cast....). That's one clear disadvantage of inline functions versus macros in my mind: no automatic polymorphism. I don't think type safety is a big win for macros like these. We need to be more judicious about which macros are scheduled for function inlining. Some just don't benefit from the type-safety implications as much as others do, and you end up requiring everyone to change their code downstream for no real reason. </div><div><br></div><div>These sorts of changes really feel to me like unnecessary spelling changes that require work from extension writers who now have to modify their code with no real gain. There seems to be a lot of that going on in the code base and I'm not really convinced that it's useful for end-users. I'm going to be a lot more resistant to that sort of change in the code base when I see it. </div><div><br></div><div>One particularly glaring example to my lens on the world: I think it would have been better to define new macros which require semicolons than changing the macros that don't require semicolons to now require semicolons: </div><div><br></div><div><div> NPY_BEGIN_THREADS_DEF</div><div> NPY_BEGIN_THREADS</div><div> NPY_ALLOW_C_API</div><div> NPY_ALLOW_C_API_DEF</div><div> NPY_DISABLE_C_API</div></div><div><br></div><div>That feels like a gratuitous style change that will force users of those macros to re-write their code. Sure, it's a simple change, but it's a simple change that doesn't do anything for you as an end user. I think I'm going to back this change out, in fact. I can't see requiring people to change their C-code like this will require without a clear benefit to them. I'm quite sure there is code out there that uses these documented APIs (without the semicolon). If we want to define new macros that require colons, then we do that, but we can't get rid of the old ones --- especially in a 1.x release. </div><div><br></div><div>Our policy should not be to allow gratuitous style changes just because we think something is prettier another way. The NumPy code base has come from multiple sources and reflects several styles. It also follows an older style of C-programming (that is quite common in the Python code base). It can be changed, but those changes shouldn't be painful for a library user without some specific gain for them that the change allows. </div><div><br></div><div>There are significant users of NumPy out there still on 1.4. Even the policy of deprecation that has been discussed will not help people trying to upgrade from 1.4 to 1.8. They will be forced to upgrade multiple times. The easier we can make this process for users the better. I remain convinced that it's better and am much more comfortable with making a release that requires a re-compile (that will succeed without further code changes --- because of backward compatibility efforts) than to have supposed ABI compatibility with subtle semantic changes and required C-code changes when you do happen to re-compile. </div><div><br></div><div>Thanks,</div><div><br></div><div>-Travis</div><div><br></div><div><br></div><div><div><div><div><div><br><div><div>On Jun 21, 2012, at 8:10 AM, Charles R Harris wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Jun 21, 2012 at 7:07 AM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<br><br><div class="gmail_quote"><div class="im">On Thu, Jun 21, 2012 at 4:11 AM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
Hey all,<br>
<br>
I made a branch called with_maskna and then merged Nathaniel's PR which removes the mask_na support from master. I then applied a patch to fix the boolean indexing problem reported by Ralf.<br>
<br>
I then created a NumPy 1.7.x maintenance branch from which the release of NumPy 1.7 will be made. Ondrej Certik and I will be managing the release of NumPy 1.7. Ondrej is the author of SymPy and has agreed to help get NumPy 1.7 out the door. Thanks, Ondrej for being willing to help in this way.<br>
<br>
In principal only bug-fixes should be pushed to the NumPy 1.7 branch at this point. The target is to make a release of NumPy 1.7.x by July 9th. The schedule we will work for is:<br>
<br>
RC1 -- June 25<br>
RC2 -- July 5<br>
Release -- July 13<br>
<br>
NumPy 1.7 is a significant release and has several changes many of which are documented in the release notes. Several new code paths were added which can have a subtle impact on code. As we make the release candidates, it will be very helpful to receive as much feedback as possible on how any changes affect your code. We will work on the release notes over the coming weeks so that they have as much information as possible.<br>
<br>
After NumPy 1.7, there is a NumPy 1.8 planned for later this year.<br>
<br></blockquote></div><div><br>Hmm, I was going to add the type specific sorts for object and structured types.<br></div></div></blockquote><div><br>Also, there is some additional cleanup that needs to be done for macros. Probably it would have been helpful to schedule the branch for a week or two in the future so we could all get the little odds and ends fixed up first.<br>
<br>Chuck <br></div><br></div>
_______________________________________________<br>NumPy-Discussion mailing list<br><a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>http://mail.scipy.org/mailman/listinfo/numpy-discussion<br></blockquote></div><br></div></div></div></div></div></body></html>