[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
Mon Jun 22 15:54:57 CDT 2009
On Mon, Jun 22, 2009 at 4:12 PM, Neil Crighton <email@example.com>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
> > >>> > 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
> Jarrod Millman's blog post about numpy and python 3 mentions this:
> > Also, there does not seem to be any advantages for python 3 for
> > scientific people ?
> I think there are lots of advantages in python 3 for scientific people.
> 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
> 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,
> it's important for people first coming to the language.
I'd like to add to that. When I advocate for python, one of the points I
make is that the community of scientific researchers who embrace python is
rapidly growing. That can be a compelling argument, it makes people much
more comfortable about investing a little time to see what it is all about.
Someone curious about python will be drawn to learn about the latest and
greatest version of the language, maybe they learn some basics, and then
they discover that the scientific libraries require an older version of the
language. The impression may be that the scientific packages are not well
enough supported to keep up with the rest of the python community, and that
it is difficult to deal with dependencies in python. Superpacks like
pythonxy and EPD can help avoid such a situation, but in the long run I
don't think our scientific python community will be well served if we don't
try surmount this obstacle.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion