On Thu, Jun 21, 2012 at 7:20 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > On Thu, Jun 21, 2012 at 9:25 AM, Travis Oliphant <tra...@continuum.io>wrote: > >> >> 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. > Well, we did do a SciPy maintenance release for this.... Overall I agree with you Chuck that cleanups are needed, but if there's too much impact for users of this particular change -- which would be nice to see confirmed by pointing to actual code instead of just asserted -- then I don't see the harm in undoing it. > > >> 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. >> > Best to have neither a re-compile nor ABI incompatibility. That said, I'd prefer the former over the latter any day of the week if I'd have to choose. Ralf > 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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
