[Numpy-discussion] Created NumPy 1.7.x branch

[Charles R Harris]

On Thu, Jun 21, 2012 at 9:25 AM, Travis Oliphant <travis at continuum.io>wrote:

> 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.
>
>
The usual practice is to announce a schedule first.


> 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.
>

What are we going to do for 1.8?


>
>
> Speaking of code changes...
>
> 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?
>

Yes, the functions will give warnings otherwise.


>   That's not as nice to type.
>

So? The point is to have correctness, not ease of typing.


>  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.
>

That's a disadvantage of Python. The virtue of inline functions is
precisely type checking.


> 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.
>
> 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.
>

Good style and type checking are useful. Numpy needs more of both.


> I'm going to be a lot more resistant to that sort of change in the code
> base when I see it.
>

Numpy is a team effort. There are people out there who write better code
than you do, you should learn from them.


>
> 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:
>
>     NPY_BEGIN_THREADS_DEF
>     NPY_BEGIN_THREADS
>     NPY_ALLOW_C_API
>     NPY_ALLOW_C_API_DEF
>     NPY_DISABLE_C_API
>
> That feels like a gratuitous style change that will force users of those
> macros to re-write their code.
>

It doesn't seem to be much of a problem.


> 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.
>
> 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.
>
>
You use that word 'gratuitous' a lot, I don't think it means what you think
it means. For instance, the new polynomial coefficient order wasn'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't make them gratuitous.


> 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.
>
>
Cleanups need to be made bit by bit. I don't think we have done anything
that will cause undo trouble.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120621/5d080fd7/attachment.html>