<br><br><div class="gmail_quote">On Tue, Jan 18, 2011 at 2:27 AM,  <span dir="ltr"><<a href="mailto:josef.pktd@gmail.com">josef.pktd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Mon, Jan 17, 2011 at 12:18 PM, Bruce Southey <<a href="mailto:bsouthey@gmail.com">bsouthey@gmail.com</a>> wrote:<br>
><br>
> Scipy release notes usually state the supported numpy version eg from<br>
> the current 0.8.0 release notes<br>
> "This release requires Python 2.4 - 2.6 and NumPy 1.4.1 or greater."<br>
> Consequently if you want to support different numpy versions, then you<br>
> will need to maintain your own branch with that type of patch. That can<br>
> get rather complex to maintain.<br>
<br>
</div></div>I'm not doing the work of maintaining a scipy that conflicts with numpy.<br>
But *if* we want to support users that run numpy 1.3 with scipy 0.7,<br>
then we need to use different arguments for calls into numpy and<br>
scipy for depreciated and changed function arguments.<br>
<div class="im"><br>
><br>
> It would be better that you change the code calling numpy/scipy<br>
> functions rather than the functions themselves such as passing the<br>
> appropriate *args and **kwargs to the function.<br>
><br>
> I would expect that a try/except block would be more general as well as<br>
> numpy.__version__ being a str.<br>
<br>
</div>Comparing strings is not a good idea, but I couldn't find anymore the<br>
function that parses a version string.<br></blockquote><div><br>There's parse_numpy_version in pavement.py. The relevant lines are:<br>  a = re.compile("^([0-9]+)\.([0-9]+)\.([0-9]+)")<br>  return tuple([int(i) for i in a.match(out).groups()[:3]])<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
As it might be obvious on the mailing list, I'm not a fan of frequent<br>
updates. With semi-annual releases, two versions only last a year.<br>
<br></blockquote><div>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.<br>
<br>Ralf<br><br></div></div>