[Numpy-discussion] compatibility for supporting more than 2 versions of numpy
ralf.gommers at googlemail.com
Tue Jan 18 10:09:45 EST 2011
On Tue, Jan 18, 2011 at 2:27 AM, <josef.pktd at gmail.com> wrote:
> On Mon, Jan 17, 2011 at 12:18 PM, Bruce Southey <bsouthey at gmail.com>
> > Scipy release notes usually state the supported numpy version eg from
> > the current 0.8.0 release notes
> > "This release requires Python 2.4 - 2.6 and NumPy 1.4.1 or greater."
> > Consequently if you want to support different numpy versions, then you
> > will need to maintain your own branch with that type of patch. That can
> > get rather complex to maintain.
> I'm not doing the work of maintaining a scipy that conflicts with numpy.
> But *if* we want to support users that run numpy 1.3 with scipy 0.7,
> then we need to use different arguments for calls into numpy and
> scipy for depreciated and changed function arguments.
> > It would be better that you change the code calling numpy/scipy
> > functions rather than the functions themselves such as passing the
> > appropriate *args and **kwargs to the function.
> > I would expect that a try/except block would be more general as well as
> > numpy.__version__ being a str.
> Comparing strings is not a good idea, but I couldn't find anymore the
> function that parses a version string.
There's parse_numpy_version in pavement.py. The relevant lines are:
a = re.compile("^([0-9]+)\.([0-9]+)\.([0-9]+)")
return tuple([int(i) for i in a.match(out).groups()[:3]])
> As it might be obvious on the mailing list, I'm not a fan of frequent
> updates. With semi-annual releases, two versions only last a year.
> Maybe you don't like the deprecation policy, but how can frequent (if
semi-annual can be called frequent) releases be a bad thing? No one likes to
write code that doesn't get released for ages.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion