On Thu, Jun 21, 2012 at 9:25 AM, Travis Oliphant <tra...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
