[Numpy-discussion] compatibility for supporting more than 2 versions of numpy

Ralf Gommers 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>
> wrote:
> >
> > 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.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110118/9b76ed7f/attachment.html>


More information about the NumPy-Discussion mailing list