Grumble about too strict an attitude about backward compatibility...
Dick.Zantow at lexisnexis.com
Mon Sep 9 09:18:58 EDT 2002
"Pearu Peterson" <pearu at cens.ioc.ee> wrote in message
news:mailman.1031563647.10076.python-list at python.org...
> On 4 Sep 2002, Skip Montanaro wrote:
> > I don't want to wake any sleeping dogs, however, as I'm sitting
> > watching a bunch of Fortran function names fly by as SciPy builds,
> > reminded of the fairly recent threads about backward
> > Python-in-a-tie, etc. Here I am compiling with a Fortran 90/95
> > (Sun's Forte thing-a-ma-bob) and see function names like
> > lpni:
> > klvna:
> > chgubi:
> > cyzo:
> > klvnb:
> > rmn2so:
> > csphik:
> > spew forth. So, while it's great that this same large library
> > runs on compilers back to at least Fortran 77 (and probably
> > programmers are still stuck with the same cryptic function and
> > they had to deal with 30+ years ago, all in the name of backward
> > compatibility.
> I don't think that its is due to the backward compatibility.
> There is huge amount of Fortran 77 code available and if one wants
> the cryptic names of functions to something more meaningful, then
> to switch to newer Fortran standard (that allows longer names) and
> huge amount of F77 code. I think nobody is willing to take this task
> to enormous amount of work (and it cannot be fully automated, some
> brain has to deside what are meaningful names), the backward
> is a secondary issue (if an issue at all).
> > What's the Python connection? Other than a reminder not to get to
> > about backward compatibility, I note that these same function
> > then go on to pollute the Python namespace because all this
Fortran code is
> > automatically wrapped using f2py.
> The Fortran function names, that you refer to, are visible only in
> extension modules that are wrapping these functions (this is due to
> Python imports shared modules). All functions that f2py generates,
> have the f2py_ prefix to avoid name collision with names from Python
> or any other library.
> So, I don't understand your argument about name pollution.
> And btw, f2py supports mapping function names so that wrapping a
> function with a name `tiarcf' can be accessed in Python side as
> `this_is_a_really_cool_function', for example.
More information about the Python-list