Describe the issue:

Since NumPy version 1.24, f2py generates for Fortran arrays of strings (e.g. CHARACTER WORD(3) * 8) a NumPy array object with dtype |S1, where the string length is added as a last dimension of the array (so the shape for the example in 1.24 is (3, 8)). In prior versions the array would have a dtype with the size of the Fortran string and the same dimensions as the Fortran type.

Reproduce the code example:

Fortran code (test.f):

      PROGRAM TEST
      
      CHARACTER        WORD*8
      CHARACTER        WORDARR(3)*8
      CHARACTER        WORDARR2(3, 4)*8
      
      COMMON  /BLOCK/  WORD, WORDARR, WORDARR2
      END

Command to generate Python module:

python -m numpy.f2py -c test.f -m test

Python test script:

import test
for attr in ('word', 'wordarr', 'wordarr2'):
    var = getattr(test.block, attr)
    print(attr, var.shape, var.dtype)

Error message:

Version 1.23.5 output:

word () |S8
wordarr (3,) |S8
wordarr2 (3, 4) |S8

Version 1.24.2 output:

word (8,) |S8
wordarr (3, 8) |S1
wordarr2 (3, 4, 8) |S1

Runtime information:

>>> import sys, numpy; print(numpy.__version__); print(sys.version); print(numpy.show_runtime())

1.24.2
3.10.4 (main, Mar 31 2022, 08:41:55) [GCC 7.5.0]
[{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
'found': ['SSSE3',
'SSE41',
'POPCNT',
'SSE42',
'AVX',
'F16C',
'FMA3',
'AVX2'],
'not_found': ['AVX512F',
'AVX512CD',
'AVX512_KNL',
'AVX512_KNM',
'AVX512_SKX',
'AVX512_CLX',
'AVX512_CNL',
'AVX512_ICL']}},
{'architecture': 'Haswell',
'filepath': '/jop91_0/eldering/anaconda3/envs/test/lib/python3.10/site-packages/numpy.libs/libopenblas64_p-r0-15028c96.3.21.so',
'internal_api': 'openblas',
'num_threads': 8,
'prefix': 'libopenblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.21'}]
None

Context for the issue:

The issue of WORD having both a shape of (8,) and a dtype of |S8 is solved by #23194. But the differences between version 1.23 and 1.24 for WORDARR and WORDARR2 remain.

The issue of equivalence between string length and array dimensions is mentioned here #19388. But I didn't get from that discussion that the way version 1.24 treats string arrays is an intended feature. Also, this difference isn't mentioned in the release notes. So I assume it is a bug. Please correct me if I'm mistaken.