[Numpy-discussion] Created NumPy 1.7.x branch
Charles R Harris
Thu Jun 21 12:20:49 CDT 2012
On Thu, Jun 21, 2012 at 9:25 AM, Travis Oliphant <email@example.com>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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion