Skip to content

g3 f2py clean up (Trac #758) #1356

@numpy-gitbot

Description

@numpy-gitbot

Original ticket http://projects.scipy.org/numpy/ticket/758 on 2008-04-26 by @pearu, assigned to @pearu.

The development of g3 f2py tool is being moved to http://launchpad.net/f2py
(see http://www.f2py.org/ for details). It means that

  1. numpy/f2py/lib directory can be removed after the move is complete.

  2. f2py script must be updated to use f2py package instead of numpy.f2py.lib when using the switch --g3-numpy.

  3. We also need a way to enable the g3 f2py tool for numpy.distutils. I can think
    of the following options:

3.1) introduce environment variable F2PY than can hold strings 'g3-numpy', '2d-numpy', '2d-numeric', '2d-numarray' that determine which f2py backends will be used by numpy.distutils.

3.2) introduce a function use_f2py(<backend name>) to numpy.distutils that can be used from setup.py files as well as from python session to set the f2py backend.

The second option may be most appropiate.

Both options have a problem of being global options. Theoretically, there may exist situations where different f2py backends must be used for different Fortran sources. The best solution would be to avoid such situations, meaning that g3 f2py must be backward compatible to numpy/f2py.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions