@2sn could you confirm that this patch works? You can test by checking out this PR and setting up numpy via spin run $SHELL and then going on to build the code you are using.

@HaoZeke Thank you very much for the fix!

I installed using

pip install git+https://github.com/numpy/numpy.git@refs/pull/27695/merge

Yes, it is including the lanedata module. Interestingly, the allocatable module variable theta, however, is not listed by dir

In [9]: dir(laneemden._solver.lanedata)
Out[9]: 
['__call__',
 '__class__',
 '__delattr__',
 '__dir__',
 '__doc__',
 '__eq__',
 '__format__',
 '__ge__',
 '__getattribute__',
 '__getstate__',
 '__gt__',
 '__hash__',
 '__init__',
 '__init_subclass__',
 '__le__',
 '__lt__',
 '__ne__',
 '__new__',
 '__reduce__',
 '__reduce_ex__',
 '__repr__',
 '__setattr__',
 '__sizeof__',
 '__str__',
 '__subclasshook__',
 'maxdata',
 'ndata']

but it is accessible, and returns None if not allocated and returns the array when allocated. Even when allocated, however, it is not listed.

In [11]: laneemden._solver.lanedata.<TAB>
maxdata ndata   
In [11]:

This may not be new behaviour (I do not recall having tried this before), but is a bit curious, and might be confusing.

Before allocating

In [5]: laneemden._solver.lanedata.theta

In [6]:

and after allocating (laneemden.solver.test())

In [10]: laneemden._solver.lanedata.theta
Out[10]: 
array([[ 1.00000000e+00,  0.00000000e+00],
       [ 9.99999999e-01, -2.03450521e-05],
       [ 9.99999998e-01, -4.06901040e-05],
       ...,
       [ 5.09606183e-06, -4.24312354e-02],
       [ 2.50628767e-06, -4.24304844e-02],
       [-8.34406605e-08, -4.24297334e-02]])

In [11]:

Awesome, thanks for the quick confirmation.

That is kind of odd. I see its because allocatable arrays get proxied into a dimension helper call f2pysetupfunc(maxdata,f2py_lanedata_getdims_theta,ndata).

This shouldn't be new behavior, but it is definitely worth reporting (and fixing).

@HaoZeke should we merge this as a fix to COMMON handling and leave the other part for later?

@HaoZeke should we merge this as a fix to COMMON handling and leave the other part for later?

Yup this fixes the common and backwards compatibility. There's an issue for the additional issue so this should be good to go.

Thanks @HaoZeke. It might be nice to backport this, and it probably deserves a mention in the release notes

@charris a backport would be great, since this also fixes #27167

I'll add a release note in a new PR.

EDIT: Done in #27730