numpy / numpy

The fundamental package for scientific computing with Python.
https://numpy.org
Other
27.54k stars 9.84k forks source link

BUG: f2py in numpy 2.0.1 does not expose variables to Python in modules containing only assignments. #27167

Open P-Kaempf opened 1 month ago

P-Kaempf commented 1 month ago

Describe the issue:

Take this F90 module:

MODULE F_GLOBALS
     IMPLICIT NONE
     INTEGER, PARAMETER :: N_MAX = 16
     INTEGER, PARAMETER :: I_MAX = 18
     INTEGER, PARAMETER :: J_MAX = 72
     ...
END MODULE F_GLOBALS

When compiled with f2py 2.0.1 and included as "f_test" in a Python script, this:

import f_test as f
maxN = f.f_globals.n_max
maxI = f.f_globals.i_max
maxJ = f.f_globals.j_max

will cause this error message:

AttributeError: module 'f_test' has no attribute 'f_globals'

Reproduce the code example:

> f2py -c -m f_test F_GLOBALS.f90

import f_test as f
maxN = f.f_globals.n_max
maxI = f.f_globals.i_max
maxJ = f.f_globals.j_max

Error message:

AttributeError: module 'f_test' has no attribute 'f_globals'

Python and NumPy Versions:

Python 3.12.4 numpy 2.0.1 Fortran compiler for the host machine: gfortran (gcc 14.1.0 "GNU Fortran (Homebrew GCC 14.1.0_2) 14.1.0") Fortran linker for the host machine: gfortran ld64 1053.12 C compiler for the host machine: cc (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)") C linker for the host machine: cc ld64 1053.12 Host machine cpu family: aarch64 Host machine cpu: aarch64

import sys print(numpy.version) 2.0.1 print(sys.version) 3.12.4 (main, Jun 6 2024, 18:26:44) [Clang 15.0.0 (clang-1500.3.9.4)]

Runtime Environment:

Python 3.12.4 (main, Jun 6 2024, 18:26:44) [Clang 15.0.0 (clang-1500.3.9.4)] on darwin Type "help", "copyright", "credits" or "license" for more information.

import numpy numpy.show_runtime() [{'numpy_version': '2.0.1', 'python': '3.12.4 (main, Jun 6 2024, 18:26:44) [Clang 15.0.0 ' '(clang-1500.3.9.4)]', 'uname': uname_result(system='Darwin', node='MBP2023.fritz.box', release='23.5.0', version='Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000', machine='arm64')}, {'simd_extensions': {'baseline': ['NEON', 'NEON_FP16', 'NEON_VFPV4', 'ASIMD'], 'found': ['ASIMDHP'], 'not_found': ['ASIMDFHM']}}, {'architecture': 'neoversen1', 'filepath': '/opt/homebrew/Cellar/openblas/0.3.27/lib/libopenblasp-r0.3.27.dylib', 'internal_api': 'openblas', 'num_threads': 10, 'prefix': 'libopenblas', 'threading_layer': 'openmp', 'user_api': 'blas', 'version': '0.3.27'}, {'filepath': '/opt/homebrew/Cellar/gcc/14.1.0_2/lib/gcc/current/libgomp.1.dylib', 'internal_api': 'openmp', 'num_threads': 10, 'prefix': 'libgomp', 'user_api': 'openmp', 'version': None}]

Context for the issue:

Code which ran fine in numpy 1.26 fails to run in numpy 2.0.1. A simple if ugly workaround is to add some executable code within the module. Only then will it become visible in Python, including all the assigned variables..

dionhaefner commented 3 weeks ago

Running into the same issue here. Our CI (which tests against a Fortran reference code) has been broken since NumPy 2.0.

charris commented 3 weeks ago

@HaoZeke Ping.

P-Kaempf commented 3 weeks ago

Until a fix comes around, you can always add some bogus executable statements to the assignment module. They do not even need to be reachable. Worked fine for me.