[Numpy-discussion] Created NumPy 1.7.x branch

[Ralf Gommers]

On Thu, Jun 21, 2012 at 7:20 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> 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
>> 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120621/9280277c/attachment.html>