[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0

[David Cournapeau]

Neil Crighton wrote:
> David Cournapeau <cournape <at> gmail.com> writes:
>
>   
>>>>> David Cournapeau wrote:
>>>>>           
>>>>>> (Continuing the discussion initiated in the neighborhood iterator
>>>>>> thread)
>>>>>>     - Chuck suggested to drop python < 2.6 support from now on. I am
>>>>>> against it without a very strong and detailed rationale, because many OS
>>>>>> still don't have python 2.6 (RHEL, Ubuntu LTS).
>>>>>>             
>>>>> I vote against dropping support for python 2.5. Personally I have no
>>>>> incentive to upgrade to 2.6 and am very happy with 2.5.
>>>>>           
>>>> Will requiring python-2.6 help the developers port numpy to python-3?
>>>>
>>>>         
>>> Can't really say at this point, but it is the suggested path to
>>> python-3.
>>>       
>> OTOH, I don't find the python 3 "official" transition story very
>> convincing. I have tried to gather all the information I could find,
>> both on the python wiki and from transitions stories. To support both
>> python 2 and 3, the suggestion is to use the 2to3 script, but it is
>> painfully slow for big packages like numpy. And there ave very few
>> stories for porting python 3 C extensions.
>>
>> Another suggestion is to avoid breaking the API when transitioning for
>> python 3. But that seems quite unrealistic. How do we deal with the
>> removing of string/long APIs ? This will impact the numpy API as well,
>> so how do we deal with it ?
>>
>>     
>
> As I understand this suggestion, they just hope external packages don't say
> 'Hey, if we're breaking backwards compatibility anyway, lets take the chance to
> do a whole lot of extra API breakage!'  That way, if people have problems 
> migrating to the new version, they know they're likely to be python 3 related.
> Jarrod Millman's blog post about numpy and python 3 mentions this: 
>
> http://jarrodmillman.blogspot.com/2009/01/when-will-numpy-and-scipy-migrate-to.html
>   

As I understand, the rationale is that by not breaking API at the same
time as py3k transition, people can migrate more easily through 2to3.
But I am really not convinced that's possible in numpy's case. I am not
100 % sure yet, but it does not look like it will be possible to support
the py3k C API without breaking things. Again, numpy is quite
particular: it is not only a big C extension, which define new types,
but it also exports a C API. So the situation is very close to python
itself, which is not backward compatible either.

> I think there are lots of advantages in python 3 for scientific people.  The 
> new integer division alone is a huge improvement.  I've been bitten by this 
> (1/2 = 0) several times in the past, and the only reason I'm not bitten by it 
> now is that I've trained myself to always type things like 1./x, which look 
> ugly.
>
> The reorganisation of the standard library and the removal of duplicate ways of
> doing things in the core also makes the language much easier to learn. This 
> isn't a huge gain for people already familiar with Python's idiosyncracies, but
> it's important for people first coming to the language.
>   

Hey, different people, different opinions. Those are really minor for
me, I am glad it matters for other people :)

> You could argue that moving to python 3 isn't attractive because there isn't 
> any scientific library support, but then that's because numpy hasn't been 
> ported to python 3 yet ;)
>   

Once numpy is ported, other softwares should be much easier. For
example, I don't expect scipy to be hard to port once numpy is ported.

David