[Numpy-discussion] Created NumPy 1.7.x branch
ralf.gommers at googlemail.com
Thu Jun 21 14:39:46 EDT 2012
On Thu, Jun 21, 2012 at 7:20 PM, Charles R Harris <charlesr.harris at gmail.com
> On Thu, Jun 21, 2012 at 9:25 AM, Travis Oliphant <travis at 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
>> 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.
> Cleanups need to be made bit by bit. I don't think we have done anything
> that will cause undo trouble.
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion