New to Python: Features

[beliavsky at aol.com]

aleaxit at yahoo.com (Alex Martelli) wrote in message news:<1gmgplx.4jmtifat3uheN%aleaxit at yahoo.com>...
> <beliavsky at aol.com> wrote:
>    ...
> > Were you using Fortran 77? Most of this version's limitations (rigid
> > source form, no abstract data types, no dynamic memory allocation, no
> > compile-time checking of procedure calls) were fixed in Fortran 90.
> 
> Although, during the '90s, I did lead several pilot projects to evaluate
> alternative language possibilities for my employer of the time, I wasn't
> the one tasked with the Fortran 90 evaluation pilot projects -- if I
> recall correctly, the CTO himself, a staunch Fortran lover, rolled his
> sleeves up and did the technical-leading himself for those; I was only
> involved in the mop-up/assessment post-project phases.  By the time F90
> compilers were mature, we were comparing against C++, and F90 came up
> short.  Not sure what you mean by saying F77 had "rigid source form":
> Fortran IV did, but F77 allowed leeway.

Fortran 90 was the first standard supporting a free source format,
where characters in the first 6 columns do NOT have special
significance and lines can be longer than 72 columns. For backwards
compatibility F90 and later versions also support fixed source format.
A file should contain either fixed or free source format code. Maybe
you were using F77 compilers with the free format extension.

<SNIP>
 
> The advantage of going to Python, rather than C++, for a C programmer,
> is that, while in Python he's going to find very different syntax, and
> (like Java) different semantics of assignment statements, in Python he's
> actually going to be operating under a _philosophy_ that's very close to
> the one that made (and still makes!) C such a roaring success: trust the
> programmer, don't stop the programmer from needing what needs to be
> done, offer only one way to perform an operation, etc -- in fact, 4.5
> out of the 5 points that the ISO C Standard identifies as "The Spirit of
> C" (the point about speed/portability tradeoffs is the only one that
> Python only meets about halfway).  People who detest that philosophy
> will of course detest Python as much as they detested (and still detest)
> C.  

In some important ways Python does NOT trust the programmer, to his
benefit.
Trying to access an out-of-bound list element or using an
uninitialized variable causes an immediate error.

> And yet Python proves that you can get a 6:1 language level ratio
> (according to Capers Jones; much more, according to Pythonistas' vast
> collective experience) _without_ abandoning simplicity and flexibility,
> indeed _increasing_ those characteristics, and dynamicity too.

I think "dynamism" is the word you are looking for :).

> and libraries in a huge variety of other languages, is crucial.  You
> mentioned C++ and F95: I would not be surprised if the best _portable_
> (across compilers and platforms) way of using both C++ and F95 in the
> same program would be exactly to interface each of them to Python!-)

The Fortran 2003 standard mandates "interoperability" with C --
Fortran calling C in a standardized way. Although it will be some time
before full F2003 compilers exist, F95 vendors are adding high-demand
features F2003 features such as C interoperability.