[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
Mon Jun 22 20:53:03 CDT 2009
Neil Crighton wrote:
> David Cournapeau <cournape <at> gmail.com> writes:
>>>>> David Cournapeau wrote:
>>>>>> (Continuing the discussion initiated in the neighborhood iterator
>>>>>> - 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
>> 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:
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
> 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.
More information about the Numpy-discussion