<br><br><div class="gmail_quote">On Thu, Jun 21, 2012 at 9:25 AM, Travis Oliphant <span dir="ltr">&lt;<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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></blockquote><div><br>The usual practice is to announce a schedule first.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div></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&#39;t feel pressured to get *everything* in this release.</div>
</div></blockquote><div><br>What are we going to do for 1.8?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">
<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&#39;s code now does PyArray_NDIM((PyArrayObject *)obj).   Is that intentional?</div>
</div></blockquote><div><br>Yes, the functions will give warnings otherwise.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">
<div>   That&#39;s not as nice to type. </div></div></blockquote><div><br>So? The point is to have correctness, not ease of typing.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div> Is that assuming that PyArray_NDIM will become a function and need a specific object type for its argument (and everything else cast....).   That&#39;s one clear disadvantage of inline functions versus macros in my mind:  no automatic polymorphism.</div>
</div></blockquote><div><br>That&#39;s a disadvantage of Python. The virtue of inline functions is precisely type checking.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div>I don&#39;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&#39;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&#39;m not really convinced that it&#39;s useful for end-users.</div>
</div></blockquote><div><br>Good style and type checking are useful. Numpy needs more of both.<br>
  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>I&#39;m going to be a lot more resistant to that sort of change in the code base when I see it.</div>
</div></blockquote><div><br>Numpy is a team effort. There are people out there who write better code than you do, you should learn from them.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><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&#39;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.</div>
</div></blockquote><div><br>It doesn&#39;t seem to be much of a problem.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">
<div>Sure, it&#39;s a simple change, but it&#39;s a simple change that doesn&#39;t do anything for you as an end user.   I think I&#39;m going to back this change out, in fact.   I can&#39;t see requiring people to change their C-code like this will require without a clear benefit to them.    I&#39;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&#39;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&#39;t be painful for a library user without some specific gain for them that the change allows. </div>
<div><br></div></div></blockquote><div><br>You use that word &#39;gratuitous&#39; a lot, I don&#39;t think it means what you think it means. For instance, the new polynomial coefficient order wasn&#39;t gratuitous, it was doing things in a way many found more intuitive and generalized better to different polynomial basis. People have different ideas, that doesn&#39;t make them gratuitous.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></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&#39;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></blockquote><div><br>Cleanups need to be made bit by bit. I don&#39;t think we have done anything that will cause undo trouble.<br><br>Chuck <br></div></div>