Python complaints

[Charles Boncelet]

I've been away for a few days and it seems I've created a minor
tempest. Thanks to all who've responded.  I have been using Python for
a few months and really like it (perhaps because I don't understand
all the little details :-)

Tim Peters wrote:

> It's a strongly typed language -- more strongly typed than C, for example.
> It's not *statically* typed, though.  It generally tries hard *not* to do
> promotions that aren't "obvious".  It was years before, e.g., "int()" was
> liberalized to accept string arguments.  It's not trying to do the merely
> reasonable, it's trying to do the hard-to-be-surprised-by.

This, I understand, is the Python way: don't do promotion unless the
meaning
is 100% clear (even then, don't do it).  This is why Python is
relatively 
easy to read, although it may take more lines to do something in Python
than
it does in, say, Perl.

However, I continue to believe that map and lambda don't enhance clarity
(except perhaps in highly unusual cases).  I do like the "list
comprehension"
syntax much more.

> 
> > (E.g., the Numeric ufuncs generally do this correctly.)
> 
> NumPy's users are presumed to be mathematical grownups for whom "the usual"
> mathematical coercions are indeed "usual".  math.sqrt(-30.2) in core Python
> is almost certainly due to someone e.g. using a numerically naive method for
> computing sample variance <1/sqrt(2*pi) wink>.  That is, as even in the
> IEEE-754 standard, sqrt(-x) is "an error" to most people.

I really like the NumPy extensions. I use Matlab a lot, but Matlab
doesn't
do a lot of the things I need to do (more complicated algorithms, www, 
minor database work, etc.).  Python+NumPy can do a lot (but, of course,
Matlab
has many functions that NumPy does not yet.) Unfortunately also, many of
my 
problems are big enough to need C extensions. (I would like to give
up C and work only in Python.)

> 
> > If Python is a typed language, shouldn't we be able to determine
> > what types are allowed as arguments and returned from functions
> > without experimentation (and reverse engineering from the source
> > code)?
> 
> Yes, but that's a long and difficult battle in a language without names for
> most of its conceptual types.  The Types-SIG is trying to address this in
> the months it isn't comatosely depressed.

This is not my area of strength, so I will wish the Types-SIG good luck.
I hope to contribute elsewhere, however.

> 
> It will take a while to get used to what you can and can't get away with!
> As general hints, don't try to be clever all the time, and get very
> comfortable with interactive mode.  Most things are actually quite
> reasonable.
> 
> the-night-stars-look-random-at-first-too-ly y'rs  - tim

Sometimes I wonder whether a middle ground between Perl's promote
everything
and Python's promote nothing might be the right balance.  But I won't
bring
this up, because I don't want to start another tempest :-)
-- 
Charles Boncelet <boncelet at udel.edu>
University of Delaware
Newark DE 19716 USA
http://www.eecis.udel.edu/~boncelet/