Grumble about too strict an attitude about backward compatibility...

[rzed]

"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
here
> > watching a bunch of Fortran function names fly by as SciPy builds,
I'm
> > reminded of the fairly recent threads about backward
compatibility,
> > Python-in-a-tie, etc.   Here I am compiling with a Fortran 90/95
compiler
> > (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
compiles and
> > runs on compilers back to at least Fortran 77 (and probably
earlier),
> > programmers are still stuck with the same cryptic function and
data names
> > 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
to fix
> the cryptic names of functions to something more meaningful, then
one has
> to switch to newer Fortran standard (that allows longer names) and
edit
> huge amount of F77 code. I think nobody is willing to take this task
due
> to enormous amount of work (and it cannot be fully automated, some
> brain has to deside what are meaningful names), the backward
compatibility
> is a secondary issue (if an issue at all).
>
> > What's the Python connection?  Other than a reminder not to get to
slavish
> > about backward compatibility, I note that these same function
names will
> > 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
the
> extension modules that are wrapping these functions (this is due to
how
> 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
Fortran
> function with a name `tiarcf' can be accessed in Python side as
> `this_is_a_really_cool_function', for example.
>
> Pearu
>
>