Needs a release note.

Do we need to generate both -f2pywrappers.f and -f2pywrappers.f90? An alternative seems to be to let users specify whether the code is F77 or F90; either way one needs a single flag when invoking f2py at the moment. I think that's still fine for determinism - the problem that was causing trouble was more "output file generated depends on details of the code". Or are there cases where f2py switches modes between F77 and F90 based on contents of a file, rather than file extension?

The .f file and .f90 files are created for different use-cases. Since F90 is a super-set of F77, it is possible for a code to trigger the generation of both the .f90 wrapper for F90 features (e.g. module) and also .f for F77 features (e.g. common).

While it isn't a good idea to mix modules and common blocks, since it is allowed by the Fortran standard (but not recommended) we can't really disallow it.

TL:DR; For F77 code the .f90 wrapper is never generated, but for F90 code, there is no way to be sure.

Other comment: why not make this the default straight away? It's fully backwards-compatible.

It is backwards-compatible, but might be confusing/annoying for downstream projects if updating causes the sudden generation of empty files. I would like it to be the default eventually though.

While it isn't a good idea to mix modules and common blocks, since it is allowed by the Fortran standard (but not recommended) we can't really disallow it.

Thanks for the explanation. That's too bad for F90 code.

It seems like for F77 though, the .f90 wrapper is never needed? I'm asking again because this deterministic mode doesn't seem to be optimal for SciPy - we now never get the -f2pywrappers2.f90, and we switch to always. They're both deterministic for F77 code (as far as I can tell), it'll just be a bit noisier after this PR. I'm not sure how reliable file extensions are, but if there is to be a CLI flag, could it be something like --always-f77wrappers/--always-f2pywrappers?

It is backwards-compatible, but might be confusing/annoying for downstream projects if updating causes the sudden generation of empty files.

Whenever it does switch the effect is the same. I suggest deciding on the final config, and either switching it now, or never. If it's now, you then don't need the command-line flag.

While it isn't a good idea to mix modules and common blocks, since it is allowed by the Fortran standard (but not recommended) we can't really disallow it.

Thanks for the explanation. That's too bad for F90 code.

It seems like for F77 though, the .f90 wrapper is never needed? I'm asking again because this deterministic mode doesn't seem to be optimal for SciPy - we now never get the -f2pywrappers2.f90, and we switch to always. They're both deterministic for F77 code (as far as I can tell), it'll just be a bit noisier after this PR. I'm not sure how reliable file extensions are, but if there is to be a CLI flag, could it be something like --always-f77wrappers/--always-f2pywrappers?

Thinking about this a little bit more then I think I'll rework this to just generate -f2pywrappers.f if the file is parsed as Fortran 77 (F2PY determines this based on more than just the extension, which is good since the filename extensions are not standardized) and to generate both *wrappers* if not.

That would probably solve this better than having a flag.

It is backwards-compatible, but might be confusing/annoying for downstream projects if updating causes the sudden generation of empty files.

Whenever it does switch the effect is the same. I suggest deciding on the final config, and either switching it now, or never. If it's now, you then don't need the command-line flag.

The only reason to have a flag is to have the option to revert to older behavior (irrespective of the default we decide on).

Discussed briefly at an F2PY meeting. The cleanest fix here is to only generate only one f2pywrappers.{ext} file with the extension changing based on the inputs.

EDIT: This is a larger refactor, and so has been moved to an issue (#21224)

The current behaviour is to generate both wrapper files for F90 sources, and only an F77 wrapper for F77 inputs with --empty-gen.

EDIT: A FutureWarning is raised when --empty-gen is not passed.

Discussed briefly at an F2PY meeting. The cleanest fix here is to only generate only one f2pywrappers.{ext} file with the extension changing based on the inputs.

EDIT: This is a larger refactor, and so has been moved to an issue (#21224)

It's not clear from the issue why this is a larger refactor, maybe expand the description a bit?

Discussed briefly at an F2PY meeting. The cleanest fix here is to only generate only one f2pywrappers.{ext} file with the extension changing based on the inputs.
EDIT: This is a larger refactor, and so has been moved to an issue (#21224)

It's not clear from the issue why this is a larger refactor, maybe expand the description a bit?

Mostly because of implementation details:

• No tests for current behavior

Also, it isn't actually clear this needs to be done in the first place, given that mixing F77 formatted code (which is what COMMON blocks generate) and F90 formatted code (generated by modules) might confuse compilers (which may have a different parser for F77 and F90).

To work around this F2PY could generate free-form wrappers to COMMON blocks when the inputs are F90 but IMO the current wrappers are more readable (-f2pywrapper.f --> common block, -f2pywrapper2.f90 --> module / derived type).

@pearu or @melissawm does this look OK?