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

josef.pktd at gmail.com josef.pktd at gmail.com
Mon Jan 17 13:27:08 EST 2011

On Mon, Jan 17, 2011 at 12:18 PM, Bruce Southey <bsouthey at gmail.com> wrote:
> On 01/17/2011 10:32 AM, josef.pktd at gmail.com wrote:
>> On Mon, Jan 17, 2011 at 11:28 AM,<josef.pktd at gmail.com>  wrote:
>>> On Sat, Jan 15, 2011 at 3:27 PM,<josef.pktd at gmail.com>  wrote:
>>>> After upgrading to numpy 1.5.1 I got caught by some depreciated
>>>> features. Given the depreciation policy of numpy, if we want to
>>>> support more than two versions of numpy, then we need some conditional
>>>> execution.
>>>> Does anyone have any compatibility functions?
>>>> I haven't looked at it carefully yet, but statsmodels might need
>>>> things like the following if we want to support numpy 1.3
>>>>     if np.__version__<  '1.5':
>>>>         freq,hsupp = np.histogram(rvs, histsupp, new=True)
>>>>     else:
>>>>         freq,hsupp = np.histogram(rvs,histsupp)
>>>> matplotlib says it supports numpy>=1.1 but I didn't see any
>>>> compatibility code that I could "borrow".
>>>> Or do I worry for nothing? The compatibility.py in statsmodels is
>>>> still almost empty.
>>> for scipy.linalg, in numdifftools, I changed this in core (in my copy)
>>>         if numpy.__version__<  '1.5':
>>>             [qromb,rromb] = linalg.qr(rmat, econ=True)
>>>         else:
>>>             [qromb,rromb] = linalg.qr(rmat, mode='economic')
>> which is of course silly, since this is for the scipy update
>>>> Josef
> 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.

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.


> Bruce
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list