On Tue, Jan 18, 2011 at 2:27 AM, <[email protected]> wrote:
> On Mon, Jan 17, 2011 at 12:18 PM, Bruce Southey <[email protected]>
> 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
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
