Python 3000 and "Python Regrets"

[beliavsky]

I just came across the slides for Guido van Rossum's "Python Regrets"
talk, given in 2002. It worries me that much of my Python code would
be broken if all of his ideas were implemented. He doesn't even like
'print'. Of course, I am not qualified to argue with Van Rossum about
the direction of Python.

When is Python "3000" expected to appear? Is there a list of expected
incompatibilities with Python 2.3? Are serious Python programmers
already taking care to avoid using Python features that may disappear
in Python 3000?
-- 
http://mail.python.org/mailman/listinfo/python-list

Replace string except inside quotes?

[beliavsky]

The code 

for text in open("file.txt","r"):
print text.replace("foo","bar")[:-1]

replaces 'foo' with 'bar' in a file, but how do I avoid changing text
inside single or double quotes? For making changes to Python code, I
would also like to avoid changing text in comments, either the '#' or
'""" ... """' kind.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: your favorite quick reference? (was Python Docs. Hardcopy 2.4 Library Reference, interested?)

[beliavsky]

O'Reilly has CD bookshelves http://cdbookshelves.oreilly.com/ ,
combining their books on a topic into a CD, for various subjects,
including Perl, but not yet for Python. I own the paper copies of
several of their Python books. A single CD containing their books

Jython Essentials
Learning Python, 2nd Edition
Programming Python, 2nd Edition
Python & XML
Python Cookbook
Python in a Nutshell
Python Pocket Reference, 2nd Edition
Python Programming on Win32
Python Standard Library

would be a great purchase, especially if upgrade prices were available
when new editions of books like "Python in a Nutshell" were released,
to keep up with changes in the language. I wonder who at O'Reilly can
be contacted to lobby for this.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lies about OOP

[beliavsky]

A paper finding that OOP can lead to more buggy software is at
http://www.leshatton.org/IEEE_Soft_98a.html

Les Hatton "Does OO sync with the way we think?", IEEE Software, 15(3),
p.46-54
"This paper argues from real data that OO based systems written in C++
appear to increase the cost of fixing defects significantly when
compared with systems written in either C or Pascal. It goes on to
suggest that at least some aspects of OO, for example inheritance, do
not fit well with the way we make mistakes."

His comments under "invited feedback" are amusing and confirm my
impression that OOP is partly (but perhaps not entirely) hype:

"I should not that this paper because it criticised OO had an unusually
turbulent review period. 2 reviewers said they would cut their throats
if it was published and 3 said the opposite. The paper was only
published if the OO community could publish a rebuttal. I found this
very amusing as my paper contains significant data. The rebuttal had
none. This sort of thing is normal in software engineering which mostly
operates in a measurement-free zone."

What papers have scientific evidence for OOP?

Paul Graham's skeptical comments on OOP are at
http://www.paulgraham.com/noop.html .

If OOP is so beneficial for large projects, why are the Linux kernel,
the interpreters for Perl and Python, and most compilers I know written
in C rather than C++?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mathmatical expressions evaluation

[beliavsky]

There is QuantLib at http://quantlib.org/ . The site says "QuantLib is
written in C++ with a clean object model, and is then exported to
different languages such as Python, Ruby, and Scheme." I have not tried
it -- if it is easily usable from Python please write back to c.l.p.

There is a Python Finance email list at
http://www.reportlab.co.uk/mailman/listinfo/python-finance .

In calculations involving bonds one needs arrays to store payment dates
and amounts etc., for which numarray should be used instead of Python
lists, for efficiency.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mathmatical expressions evaluation

[beliavsky]

Paul McGuire wrote:
>And I wouldn't necessarily agree with beliavsky's assertion that
numarray
>arrays are needed to represent payment dates and amounts, unless you
were
>going to implement a major banking financial system in Python.

Maybe arrays are not "needed", but especially for vectors of floating
point numbers, I prefer to use a Numeric array rather than a list
because

(1) array operations like sum and exp are possible, and I want z = x +
y to perform an element-wise sum rather than a concatenation of lists.
Given arrays containing a set of times, coupon amounts, and interest
rates, the value of a bond could be a calculated with a single
expression, without loops.

(2) A TypeError is raised if I do something illogical like

x = zeros(3,Float)
x[0] = "dog"

(3) Higher-dimensional arrays are better represented with Numeric or
Numarray arrays than with lists.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Complementary language?

[beliavsky]

Robert Kern wrote:
>If you do numeric calculations, learning just enough FORTRAN to do
loops
>and math can be quite useful. I find that F2PY makes writing FORTRAN
>subroutines for numerical calculations over Numeric arrays much easier

>than C.

I agree with this and would add that Fortran, from the 1990 standard
onwards, is one of the few compiled languages that support both array
operations and multidimensional array slices, like the Python Numeric
and Numarray modules (and lists for 1-D arrays). There is a free
Fortran 95 compiler called g95 at http://www.g95.org .

In some ways, the syntax of Python is closer to free format Fortran
than C.

Maybe the message
http://groups-beta.google.com/group/comp.lang.python/msg/5de999e28ead0dd9
I wrote with comparative statistics on some programming languages could
be informative.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what would you like to see in a 2nd edition Nutshell?

[beliavsky]

I like the current edition. Since it is a reference work, I would like
to see it in a CD-ROM as well as in print, either packaged with a book
or as part of a Python CD Bookshelf, analogous to the other CD
bookshelves O'Reilly offers.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[beliavsky]

Bulba wrote:
>OK, so what projects and why would you consider
>Python:
>1. "clearly unsuitable"

Large-scale scientific computing projects, such as numerical weather
prediction, where performance is critical. Python could be used as the
"glue" but not the "guts", where Fortran 95 and C++ are more
appropriate. In my tests, some posted here, there has been a
significant speed differential between Fortran 95 and Python with
Numeric. I don't know if using Numarray instead would change the
results.

Calling an extension written in C, such as Numeric, can improve
performance greatly over using "pure" Python, but the speed of
evaluating simple expressions can still be close to 2 orders of
magnitude slower.

Here is an example that computes
(1) sum(x)
(2) sum(x**2)
(3) sum((x-0.5)**2)

for 1E7 uniformly distributed random numbers.

# Python
from RandomArray import random
from timeimport time
from Numeric import sum
n= 1000
half = 0.5
x= random(n)
for iopt in range(1,4):
t1 = time()
if (iopt == 1):
xsum = sum(x)
elif (iopt == 2):
xsum = sum(x**2)
elif (iopt == 3):
xsum = sum((x-half)**2)
t2 = time()
print iopt,xsum,t2-t1

! Fortran 95
program xsum_power
implicit none
integer, parameter :: n = 1000
real(kind=8)   :: x(n),xsum,t1,t2
real   , parameter :: half = 0.5
integer:: iopt
iopt = 1
call random_seed()
call random_number(x)
do iopt=1,3
call cpu_time(t1)
select case (iopt)
case (1) ; xsum = sum(x)
case (2) ; xsum = sum(x**2)
case (3) ; xsum = sum((x-half)**2)
end select
call cpu_time(t2)
write (*,"(i4,100f16.6)") iopt,xsum,t2-t1
end do
end program xsum_power

The approximate times taken in seconds, in Python and Fortran, are

task  Fortran   Python
sum(x)  0.05   0.1
sum(x**2)  0.05   2.4
sum((x-0.5)**2)  0.05   3.2

In the Fortran code, essentially all the time is spent accessing the
array elements. Powers and subtractions in array operations seem to be
free in Fortran but very expensive in Python with Numeric.

Not wanting to be guilty of "premature optimization", I did not try to
make either code more efficient than my first attempt. The Fortran
compiler is Compaq Visual Fortran 6.6c, and the Python used is 2.2.

-- 
http://mail.python.org/mailman/listinfo/python-list

OT: spacing of code in Google Groups

[beliavsky]

When I copy code from a source file into a Google Groups message, the
indentation is messed up, making my Python code illegal and all my code
ugly. Are there tricks to avoid this?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Looping using iterators with fractional values

[beliavsky]

Mike Meyer wrote:

>Or - and much safer when dealing with floating point numbers - iterate
>over integers and generate your float values:

>for j in range(1, 9):
>   i = j * .25
>   print "%9.2f" % i

I agree with this suggestion. As an historical aside, Fortran had loops
with floating point variables for decades, but in 1995, the first
standard in a while to REMOVE features, this was one of the few things
deleted. The Fortran standards committee is very conservative about
creating backwards incompatibilities, but they must have thought loops
with floating point variables are so error-prone -- and alternatives
with integer counters are so easy to write -- that they put their foot
down. I know the OP is asking about Python, but the principle is the
same.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[beliavsky]

Paul Rubin wrote:
>I don't find static type declarations to have much cost. It's just a
>few more keystrokes. I'm open to persuasion about whether they have
>benefit.

Overall I agree with you and would like to have OPTIONAL static type
declarations in Python, as has often been discussed. But without
facilities for generic programming, such as templates in C++, static
type declarations can force one to duplicate a LOT of code, with one
sorting routine each for integer, floats, strings, etc. Some algorithms
are type invariant, and Python is a concise language for expressing
those algorithms.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Approximating scattered data

[beliavsky]

Grant Edwards wrote:
>I've been looking for some way to approximate scattered 3D data
>points in Python. The data doesn't seem to be amenable to
>fitting functions like polymials, so I may have to use
>something more like a spline surface.

>However, I can't find anything usable from Python, and my
>Fortram skills are pretty rusty. I tried SciPy, but it's spline
>fitting module doesn't work at all for my data. I've found
>mentions of a Python port NURBS toolbox, but all the links I
>can find are broken.

NURBS is available in Matlab and Scilab at
http://www.aria.uklinux.net/nurbs.php3 , and translating to Python with
Numeric/Numarray should not be too hard.

If you are trying to fit z = f(x,y) without having a particular
functional form in mind, you can apply a nonparametric regression
technique. One of the easiest approaches to code is Nadaraya-Watson
kernel regression -- see for example
http://www.quantlet.com/mdstat/scripts/spm/html/spmhtmlnode24.html ,
equation 4.68, where a Gaussian kernel can be used for K. PyML at
http://pyml.sourceforge.net/doc/tutorial/tutorial.html may implement
this (I have not tried it). LIBSVM at
http://www.csie.ntu.edu.tw/~cjlin/libsvm/ has a Python interface for
Support Vector Machines, a fairly popular and recent flexible
regression method.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[beliavsky]

Roy Smith wrote:
>I think you've hit the nail on the head. In awk (and perl, and most
>shells, and IIRC, FORTRAN), using an undefined variable silently gets
>you a default value (empty string or zero). This tends to propagate
>errors and make them very difficult to track down.

You may recall correctly, but Fortran compilers have improved. The
following Fortran 90 program

integer, parameter :: n = 1
real :: x,y=2.0,z(n)
print*,"dog"
print*,x
z(n+1) = 1.0
print*,z
end

has 3 errors, all detected at compile time by the Lahey/Fujitsu Fortran
95 compiler, with the proper options:

2004-I: "xundef.f", line 2: 'y' is set but never used.
2005-W: "xundef.f", line 4: 'x' is used but never set.
2153-W: "xundef.f", line 5, column 1: Subscript out of range.

At run time, the output is

dog
The variable (x) has an undefined value.
Error occurs at or near line 4 of _MAIN__

Running Python 2.4 on the Python analog,

n = 1
y = 2.0
z = range(n)
print "dog"
print x
z[n] = 1.0
print z

one error is caught:

dog
Traceback (most recent call last):
File "xundef.py", line 5, in ?
print x
NameError: name 'x' is not defined

You will see the out-of-bounds error for z only after fixing the
undefined-x error. No warning is ever given about y, which is set but
never used. In practice, 'print "dog"' could be some operation taking
hours. Can PyChecker find all the problems in a single run, without
executing 'print "dog"'? If so, it would be great if it were integrated
with the CPython interpreter.

One reason interpreted languages like Python are recommended to
beginners is to avoid the edit/compile/debug cycle. But I think it is
faster and less frustrating to have many errors caught in one shot.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is python more popular than coldfusion?

[beliavsky]

>is python more popular than coldfusion?

>I realsie that is a very general question as one thing does not
directly
>relate to the other. My issue is that I am ditching coldfusion due to
>there being next to no work for it, and I am thinking of taking on
>python as a second language to java in the hope of improving my
resume.

For your specific purpose of learning a language to get a job, I
suggest visiting the site http://mshiltonj.com/sm/categories/languages/
, where it appears that Python is mentioned about as often as Fortran
or Ada in job listings at dice.com . Apart from Java, two languages in
demand are C++ and Visual Basic. C++ may be easier to learn along with
Java since the syntax is similar, but VB is a very easy language to
learn and use.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is python more popular than coldfusion?

[beliavsky]

OTOH,

Here are the numbers for Average Salary by Languages Used (2 numbers,
staff and management) in ascending order from the 2004 Salary Survey
from Software Development Magazine. I am surprised that there is so
little variation across languages: 13 out of 22 are in the $81-$85K
range. But Python IS tied for first. This may indicate that the
relatively small number of jobs listing Python as a requirement is due
in part to a relatively small supply of Python programmers, not lack of
demand for such programmers.

Delphi/Object Pascal $76K $96K
Cobol $76K $95K
EDI $78K $98K
.NET $79K $98K
Oracle/SQL Server/Sybase/database $80K $100K
SAP/PeopleSoft/Oracle/ERP $81K $100K
C# $81K $100K
Perl/Javascript/PHP/scripting $81K $100K
Lotus Notes/groupware $82K $101K
Java $83K $102K
Fortran $83K $102K
C++ $84K $103K
JavaBeans/ActiveX/component $84K $101K
C $84K $104K
Ada $84K $105K
Biztalk/Crossworlds/bus. integration $84K $99K
SOAP $85K $103K
J2EE $85K $105K
CORBA/COM/middleware $87K $106K
J2ME $88K $104K 
Python $89K $105K 
Java messaging $89K $106K

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to extract columns like awk $1 $5

[beliavsky]

It takes a few more lines in Python, but you can do something like

for text in open("file.txt","r"):
words = text.split()
print words[4],words[5]
(assuming that awk starts counting from zero -- I forget).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: DOS problem (simple fix??)

[beliavsky]

When I have a Python script generating a lot of output, I either open
an output file and then print to it with

fp = open("results.txt","w")
print>>fp,"stuff"

or I redirect output to a file from the command line using ">" (also
works on Unix), for example

python foo.py > results.txt

An alternative is to open a shell buffer within Emacs or XEmacs, two
text editors with Python modes. You can run a Python script from within
the shell buffer, and the results will be printed there. You can move
around the shell buffer as if it were a file.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Another look at language comparisons

[beliavsky]

>From the web site:
"Why Microsoft can Blow-Off with C#? These people have thought up
programming languages Fortran, Prologue, Ada."

The author is ignorant. Fortran was invented by IBM in the late 1950s,
long before Microsoft existed. Ada was commissioned by the U.S.
Department of Defense in the 1970s. The Prolog programming language is
not spelled "Prologue".

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Other notes

[beliavsky]

Bengt Richter wrote:

>OTOH, there is precedent in e.g. fortran (IIRC) for named operators of
the
>form .XX. -- e.g., .GE. for >= so maybe there could be room for both.

Yes, but in Fortran 90 "==", ">="  etc. are equivalent to ".EQ." and
".GE.". It is also possible to define operators on native and
user-defined types, so that

Y = A .tx. B

can be written instead of the expression with the F90 intrinsic
functions

Y = matmul(transpose(A),B)

The Fortran 95 package Matran at
http://www.cs.umd.edu/~stewart/matran/Matran.html uses this approach to
simplify the interface of the Lapack library and provide syntax similar
to that of Matlab and Octave.

I don't know if the syntax of your idea clashes with Python, but it is
viable in general.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: read numbers from file and covert to integer

[beliavsky]

If you have a file "ints.txt" with contents

10 20
30
40 50 60

You could read integers into a list with

ivec = []
for text in open("ints.txt","r"):
words = text.split()
for x in words:
ivec.append(int(x))
print ivec

If you know you want to read two integers into variables a,b from a
line you could write

a,b = int(words[0]),int(words[1])

Excuse me, but if your question is really so elementary that this post
answered it, you should probably read a book or tutorial.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python3: on removing map, reduce, filter

[beliavsky]

Steve Holden wrote:
>>   def square(x):
>>   return x*x
>>   map(square, range(1000))

>> versus

>>   [x*x for x in range(1000)]

>> Hint: function calls are expensive.

>$ python -m timeit -s "def square(x): return x*x" "map(square,
range(1000))"
>1000 loops, best of 3: 693 usec per loop

>$ python -m timeit -s "[x*x for x in range(1000)]"
>1000 loops, best of 3: 0.0505 usec per loop

Functions will often be complicated enought that inlining them is not
feasible. In Fortran 95 one can define an elemental function that takes
an argument of any shape (scalar, vector, matrix etc.) but of a
specified type, returning a result of the same shape, so that one could
write

elemental function square(i) result(isq)
integer, intent(in) :: i
integer   :: isq
isq = i*i
end function square

and then

print*,square((/i,i=0,999/))

The Numeric and Numarray Python modules have predefined ufunc's that
are essentially elemental functions with one or two arguments. It would
be nice if one could define new ufunc's using only Python code -- I
presume new ones can currently be added by writing C code.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 2.3.4 for windows: float("NaN") throws exception

[beliavsky]

Tim Peters wrote:
>Neither -- all Python behavior in the presence of float NaNs,
infinities, or signed zeroes is a platform-dependent accident.

C99 and Fortran 2003 have IEEE arithmetic. If CPython could be compiled
with a C99 compiler, would it also have IEEE arithmetic? Do Python
number-crunchers think this is important?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OCAMl a more natural extension language for python?

[beliavsky]

Jelle Ferringa wrote:

>Since I haven't got actual experience programming CAML I'd like to
speculate
>that OCAML would be a very pythonic way of extending python: its
>open-source, object oriented, as fast as C, and ! garbage collecting!

The open source g95 Fortran 95 compiler is already usable and will be
officially released this year. Fortran and C are comparable in speed,
and if one uses allocatable arrays rather than pointers, memory leaks
should not occur. Fortran 2003 supports OOP with inheritance, and a few
F95 compilers already have this functionality.

>That's depending on how you compare; I find OCAML quite readable
compared to C / Fortran .

Have you ever used Fortran 90 or 95?

I don't use OCAML, so I looked at some OCAML code to multiply matrices
at
http://shootout.alioth.debian.org/benchmark.php?test=matrix&lang=ocaml&id=0&sort=cpu
from the Computer Language Shootout . To create a matrix the OCAML code
is

7 let mkmatrix rows cols =
8   let count = ref 1 and last_col = cols - 1
9   and m = Array.make_matrix rows cols 0 in
10   for i = 0 to rows - 1 do
11 let mi = m.(i) in
12 for j = 0 to last_col do mi.(j) <- !count; incr count done;
13   done;

In Python with Numeric it's just

x = zeros([nrow,ncol],Float)

and in Fortran 90/95 it's just

real, allocatable :: x(:,:)
allocate (x(nrow,ncol))

There appears not to be a built-in function for matrix multiplication
in OCAML. There is in Python with Numeric or Numarray or Fortran 90/95.
For problems where the main data structures are arrays, OCAML seems to
be considerably more low-level than Python with Numeric/Numarray or
Fortran 90/95. Also, there exists a vast computational infrastructure
in Fortran and C (see http://www.netlib.org). Does OCAML have this?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: dynamic data types

[beliavsky]

rbt wrote:

>I've always thought of it like this... in C, we have to do something
>like this when declaring a variable:

>int x = 0;

>We had to specifically tell the language compiler that x is an
integer.
>In Python, all we have to do is:

>x = 0

>The interpretor knows that x is an integer. We can also change the
type
>like this:

>str(x)
>float(x)
>long(x)

Just to clarify, str(x) does not change x, but

x = str(x)

does. Probably rbt knows this. I wonder how often this feature should
be employed. In my Python programs, most variables keep the same type
throughout. This makes a code easier for me to understand, and this
constraint should facilitate translation of the code to a statically
typed language (perhaps even a variant of Python) in the future, if
necessary.

The ability to grow a list with "append" is a very convenient feature
of Python. The C++ vector is similar but stores elements of the same
type, whereas a Python list or tuple can store elements of different
types.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Good C++ book for a Python programmer

[beliavsky]

Rick Muller wrote:
>I was wondering whether anyone could recommend a good C++ book, with
>"good" being defined from the perspective of a Python programmer.

The STL and the template feature of C++ gives the programmer some of
the functionality of Python (using templates instead of duck typing,
vectors instead of lists etc.), so a book that introduces these
features early, such as "Accelerated C++" by Koenig and Moo, could be a
good start for a Pythonner. The 4th edition of the well-known "C++
Primer", with Moo as a new co-author, will soon be published. It is a
more comprehensive and much longer book.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: problems with duplicating and slicing an array

[beliavsky]

Yun Mao wrote:

>I have some questions when I'm using python numeric:

>1. When I do v = u[:, :], it seems u and v still point to the same
>memory. e.g. When I do v[1,1]=0, u[1,1] will be zero out as well.
>What's the right way to duplicate an array? Now I have to do v =
>dot(u, identity(N)), which is kind of silly.

You can use v = 1*u or v  = u.copy() to get the type of copy you want.

>2. Is there a way to do Matlab style slicing?

Use the take function.

The output of the following code

from Numeric import array,take
a = array([1,2])
b = a
c = 1*a
d = a.copy()
a[0] = 3
print b
print c
print d
print take(a,[1,0,1])

is

[3 2]
[1 2]
[1 2]
[2 3 2]

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: problems with duplicating and slicing an array

[beliavsky]

Yun Mao wrote:
>Thanks for the help. numarray doesn't provide what I look for either.
e.g.
>a = array( [[1,2,3],[4,5,6]] )
>I sometimes what this:  a[ [1,0], :],  or even
>a[ [1,0], [0,1] ] , which should give me
>[[4, 5], [1,2]]

I think Fortran 90 and 95 have the array slicing you want. For example,
if

imat =
111213
212223

then imat([2,1,2],:)) =
212223
111213
212223

and imat([2,1,2],[1,3]) =
2123
1113
2123

Like Matlab, Fortran arrays by default start with 1, and x(i:j) gives a
slice of elements including x(j). There are free compilers g95 (in
beta) and gfortran (in alpha).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Browsing text ; Python the right tool?

[beliavsky]

Here is an elementary suggestion. It would not be difficult to write a
Python script to make a csv file from your text files, adding commas at
the appropriate places to separate fields. Then the csv file can be
browsed in Excel (or some other spreadsheet). A0 and C1 records could
be written to separate csv files.

There are Python programs to create Excel spreadsheets, and they could
be used to format the data in more sophisticated ways.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python without OO

[beliavsky]

Peter Maas wrote:
> Davor schrieb:
> > so initially I was hoping this is all what Python is about, but
when I
> > started looking into it it has a huge amount of additional (mainly
OO)
> > stuff which makes it in my view quite bloated now.
>
> So you think f.write('Hello world') is bloated and
file_write(f,'Hello world')
> is not? This is the minimum amount of OO you will see when using
Python. But
> I guess you will use OO in the long run to *avoid* bloated code:
>
> --snip---
>
> print  "*** Davor's evolution towards an OO programmer ***"
>
> print '\n*** Step 1: OO is evil, have to use atomic variables:'
>
> name1 = 'Smith'
> age1 = 35
> sex1 = 'male'
> name2 = 'Miller'
> age2 = 33
> sex2 = 'female'
>
> print name1, age1, sex1, name2, age2, sex2
>
> print '\n*** Step 2: This is messy, put stuff in lists:'
>
> p1 = ['Smith', 35, 'male']
> p2 = ['Miller', 33, 'female']
>
> for e in p1:
>  print e
>
> for e in p2:
>  print e

Being a Fortranner, my "Step 2" would be to use parallel arrays:

names = ['Smith','Miller']
ages  = [35,33]
sexes = ['male','female']

for i in range(len(names)):
print names[i],ages[i],sexes[i]

There are disadvantages of parallel arrays (lists) -- instead of
passing one list of 'persons' to a function one must pass 3 lists, and
one can unexpectedly have lists of different sizes if there is a bug in
the program or data file. But there are advantages, too. Sometimes one
does not need to pass the entire data set to a function, just one
attribute (for examples, the ages to compute the average age). This is
more convenient with parallel arrays than a list of objects (although
it's easy in Fortran 90/95).

I am not saying that parallel arrays are better than classes for
storing data, just that they are not always worse.

It is a strength of Python that like C++, it does not force you to
program in an object-oriented style. Lutz and Ascher, in the 2nd
edition of "Learning Python", do not mention OOP for almost the first
300 pages. They say (p297)

"Python OOP is entirely optional, and you don't need to use classes
just to get started. In fact, you can get plenty of work done with
simpler constructs such as functions, or even simple top-level script
code. But classes turn out to be one of the most useful tools Python
provides ..."

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python without OO

[beliavsky]

Nick Coghlan wrote:
> Davor wrote:
> > thanks for the link
> >
> >
> >>know what's funny: in the Lua mailing list there is currently a
> >>discussion about adding OO to Lua.
> >
> >
> > I guess most of these newer languages have no choice but to support
OO
> > if they want to attract a larger user base :-(...
>
> Tell me, have you ever defined a C structure, and then written
various functions
> to operate on that structure (i.e. taking a pointer to the structure
as their
> first argument)?
>
> Have you then put both the structure definition and the function
prototypes into
> a single header file and used that header file from other code?
>
> That's OO programming: associating several pieces of information as
an 'object',
> and associating various methods to operate on instances of those
objects.

Then why was C++ invented? What you have described can be done in C,
Pascal, and Fortran 90, all of which are generally classified as
procedural programming languages. As Lutz and Ascher say in "Learning
Python", in object-based programming one can pass objects around, use
them in expressions, and call their methods. "To qualify as being truly
object-oriented (OO), though, objects need to also participate in
something called an inheritance hierarchy." Whether true OOP is a Good
Thing is arguable and depends on the situation.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python without OO

[beliavsky]

John Hunter wrote:
> > "Davor" == Davor  <[EMAIL PROTECTED]> writes:
>
> Davor> not really - it was not my intention at all - but it seems
> Davor> people get upset whenever this OO stuff is mentioned - and
> Davor> what I did not expect at all at this forum as I believed
> Davor> Python people should not be so OO hardcore (seems not all
> Davor> as quite a few have indicated in their
> Davor> replies)... Nevertheless, I think the discussion has
> Davor> several quite good points!  --
> Davor> http://mail.python.org/mailman/listinfo/python-list
>
> Consider the case of a list, say
>
> x = [1,2,3,4]
>
> suppose you wanted to reverse the list, so that x becomes [4,3,2,1].
> In a procedural language, one might do
>
>   x = reverse(x)
>
> In an OO language such as python, one might do
>
>   x.reverse()
>
> Is the OO way more obscure and complicated, etc?  Not really -- it's
> only a minor syntactical difference.  One of the core ideas behind OO
> programming is that data (the contents of the list 1,2,3,4) and
> methods (sorting, reversing) are bound together into a single entity,
> the object.  On the face of it, this is rather sensible.

I think the OO way is slightly more obscure. It's obvious what x =
reverse(x) does, but it is not clear unless you have the source code
whether x.reverse() reverses x or if it returns a reversed list. If
x.reverse() does the former, a disadvantage relative to the procedural
approach is that a function can be used in an expression. It is clearer
and more concise to write

z = reverse(x) + reverse(y)

than

x.reverse()
y.reverse()
z = x + y

Furthermore, if in Python the algorithm for the reverse function
applies to many kinds of objects, it just needs to be coded once,
whereas a reverse method would have to provided for each class that
uses it (perhaps through inheritance).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python without OO

[beliavsky]

[EMAIL PROTECTED] wrote:

> >> There is not much than can be done at the Python level. But I
would
> >> see with interest a Python spinoff geared towards simplicity.
>
> >I think this would be useless because advanced concepts exist for
> >a reason. A simplified spin-off would aquire advanced concepts
> >over time and would just become a clone of Python.
>
> And then we will need another simplified spinoff ;)
> There is always a fight between simplificity and complexity.
> Some complexity is not needed, and I am sure even in Python
> something could be dropped. But it is difficult to find what can
> be removed. Remember that Saint-Exupery quote? Something
> like "a work of art is finished when there is nothing left to
remove?"
> M.S.

"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."

I know this quote because it is the motto of the F programming language
http://www.fortran.com/F/ , a "simplified spinoff" of Fortran 95.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what's OOP's jargons and complexities?

[beliavsky]

PA wrote:

> Plus, a man which such cinematographic tastes [1] cannot be entirely
> bad :P
>
> http://xahlee.org/PageTwo_dir/Personal_dir/favorite_movies.html

The site proves he is evil. Grep "Titus" if you have a strong stomach.
I'm sure you did not get that far.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Coding style article with interesting section on white space

[beliavsky]

Nick Coghlan wrote:
> Thought some folks here might find this one interesting. No great
revelations,
> just a fairly sensible piece on writing readable code :)
>
> The whole article:
>
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=271&page=1
>
> The section specifically on white space:
>
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=271&page=3

The suggestions in the cited article, "How Not to Write FORTRAN in Any
Language", are reasonable but elementary and can be followed in Fortran
90/95/2003 as well as any other language. What infuriates me is that
the author writes as if Fortran has not evolved since the 1960s. It
has. To be specific, Fortran 90

(1) allows variable names up to 31 characters long
(2) has a free source form where
(a) there are no rigid rules about starting code in a certain
column
(b) white space is significant
(3) has a full set of control structures -- goto's are almost never
needed

More detailed rebuttals of the article are in the archives of the
Fortran 90 discussion group at
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind0501&L=comp-fortran-90
-- search for "Fortran bashing".

Python looks more like Fortran 90 than one of the curly-brace/semicolon
languages, and both languages have modules and array slices.

One ought to do a little research before publishing an article.
Apparently, many authors and editors are too lazy to do so.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Coding style article with interesting section on white space

[beliavsky]

Michael Tobis wrote:
> (unwisely taking the bait...)
>
> If you like your language to look like this
> http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html
> then more power to you.

Thanks for pointing out that interesting article on Fortran 90 bugs.
How long would a comparable C++ list be? Even Python has gotchas, for
example the difference between deep and shallow copies.

> I prefer my languages to be portable, terse and expressive.

Fortran programmers are generally happy with the portability of the
language. A difficulty with Python portability and maintainability is
that some needed functionality is not in the core language but in C
extensions. For scientific computation, consider the case of Numeric
and Numarray. I don't think Numeric binaries are available for Python
2.4, and Numarray is not perfect substitute, being considerably slower
for small arrays, having slightly different functionality in some
areas, and
as recently as Nov 2004 (c.l.py thread "numarray memory leak") leaking
memory when multiplying matrices.

The recent "Pystone Benchmark" message says that Python is only 75% as
fast on Linux as on Windows. Fortran programs do not suffer this
performance hit and are in this respect more portable. In theory, as
has been mentioned, one could use a faster compiler to compile CPython
on Linux, but AFAIK this has not yet been done.



> There is no fundamental reason why a language with expressive power
> much like Python's cannot have run-time performance comparable to
> Fortran's. Unfortunately, Fortran's dominance of the relatively small
> scientific computation universe has prevented such a language from
> emerging.

Nobody is stopping Python developers from working on projects like
Psyco.

> The solutions which interest me in the short run are 1)
> writing a code generation layer from Python to a compiled language
> (possibly F77 though I will try to get away with C) and 2) wrapping
> legacy Fortran in Python. The latter is quite regularly subverted by
> non-standard binary data structures across compilers and a pretty
> profound disinterest in interoperability by the people designing the
> Fortran standard that makes their interest look more like turf
> protection and less like an interest in the progress of science.

So uninterested in interoperability is the Fortran standards committee
that they added interoperability with C in Fortran 2003 standard.



> Python fundamentally respects the programmer.

What does that mean?

> Fortran started from a point of respecting only the machine, (which
is > why Fortrans up to F77, having a well-defined objective, were
> reasonable)

I have found that Fortran 90/95 is better at the objective of FORmula
TRANslation for array expressions (mostly what I need) than previous
versions.

> but now it is a motley collection of half-baked and
> confusing compromises between runtime performance, backward
> compatibility,  and awkward efforts at keeping up with trends in
> computer languages.

This is true to some extent of any language "of a certain age",
including C++.



> For more see http://www.fortranstatement.com

And the rebuttal at http://www.fortranstatement.com/Site/responses.html
.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Coding style article with interesting section on white space

[beliavsky]

Alex Martelli wrote:



> > For scientific computation, consider the case of Numeric
> > and Numarray. I don't think Numeric binaries are available for
Python
> > 2.4,
>
>  ?  Just
> googled and visited the first hit -- I don't currently use Windows so
I
> don't know if it's still there, works well, etc.

I should have Googled. I will investigate that link. At SourceForge,
http://sourceforge.net/project/showfiles.php?group_id=1369 I see a
Numarray but not a Numeric Windows binary for Python 2.4. The latest
Numeric Windows binary there is for Python 2.3.

>
> > The recent "Pystone Benchmark" message says that Python is only 75%
as
> > fast on Linux as on Windows. Fortran programs do not suffer this
> > performance hit and are in this respect more portable. In theory,
as
>
> You're saying that using a different and better compiler cannot speed
> the execution of your Fortran program by 25% when you move it from
one
> platform to another...?!  This seems totally absurd to me, and yet I
see
> no other way to interpret this assertion about "Fortran programs not
> suffering" -- you're looking at it as a performance _hit_ but of
course
> it might just as well be construed as a performance _boost_ depending
on
> the direction you're moving your programs.

I had in mind the Polyhedron Fortran 90 benchmarks for Windows and
Linux on Intel x86 at
http://www.polyhedron.co.uk/compare/linux/f90bench_p4.html and
http://www.polyhedron.co.uk/compare/win32/f90bench_p4.html . The speed
differences of Absoft, Intel, and Lahey between Linux and Windows for
individual programs, not to mention the average differential across all
programs, is much less than 25%. The differences on a single OS between
compilers can be much larger, but that has less bearing on portability
across OS's.

Thanks for your earlier informative comments on languages. Sparring
with Alex Martelli is like boxing Mike Tyson, except that one
experiences brain enhancement rather than brain damage :).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Need programming tip

[beliavsky]

A Usenet tip is that one should never use such a generic subject as
"need programming tip" or the ever-popular "newbie question". In this
case, "create a database of posts made to binary groups" could have
been a better title, so that people unable to answer to the question
and not interested in the topic can skip it.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regarding exception handling

[beliavsky]

Aggelos I. Orfanakos wrote:
> (I don't know why, but indentation was not preserved once I posted.)

This problem and its possible solutions was discussed here in the
thread "OT: spacing of code in Google Groups".

-- 
http://mail.python.org/mailman/listinfo/python-list

Fortran pros and cons (was Re: Coding style article with interesting section on white space)

[beliavsky]

Michael Tobis wrote:

> > Fortran programmers are generally happy with the portability of the
> > language.
>
> Until they try to port something...? Honestly, I can't imagine where
> anyone would get this impression.

>From the fact that Fortran has been used on hundreds of platforms and
that many portable libraries like LAPACK exist. Fortran 90+ allows one
to write even more portable code using the KIND mechanism and the
selected_int_kind and selected_real_kind functions, which let you
specify the ranges of basic data types.

> Now, about the terseness and expressiveness?

Fortran 90/95 is more expressive than Fortran 77 in many ways, as
described in (for example) pages 7-8 of the essay "Numerical Recipes:
Does This Paradigm Have a Future?", available at
http://www.nr.com/CiP97.pdf . Quoting that paper:

"This, for us, was the revelation of parallel programming in Fortran
90.
The use of parallel and higher-level constructions -- wholly
independently of whether they are executed on tomorrow's parallel
machines or today's ordinary workstations -- expresses more science per
line of code and per programming workday. Based on our own experience,
we think that productivity, or achievable complexity of project, is
increased a factor of 2 or 3 in going from Fortran 77 to Fortran 90 --
if one makes the investment of mastering Fortran 90's higher level
constructs."

> > For scientific computation, consider the case of Numeric
> > and Numarray.
>
> I'm not happy with these, because they either make temporary arrays
> with wild abandon

Some early Fortran 90 compilers did this but have improved
significantly in this respect.

> or enforce an unnatural style of expression.

I wonder what this means.



> I do not suggest that Python is currently competitive with C++ or
> Fortran. I simply agree with
> http://www.fortranstatement.com that something new ought to be
> designed, that a backward compatible Fortran2003 cannot possibly be
it,
> and that attention to fortran diverts resources from [the sort] of
> genuine progress that ought to be possible.

You have not given specifics about what "genuine progress" in a
scientific programming language would be.



> Performance portability has nothing to do with what I'm talking
about.
>
> The answer belies the attitude that programmers are there to put in
> time and expend effort, because the only resource worth considering
is
> production cycles on a big machine.

Nonsense. Fortran was originally created to make PROGRAMMERS more
efficient by letting them code algebraic expressions instead of machine
code.

> This attitude explains why working with Fortran is so unpleasant an
> experience for anyone who has been exposed to other languages.

"Anyone"? Since I have been exposed to Python and C++ and still find
Fortran 90+ enjoyable, your statement is demonstrably false. Have you
ever used a version of Fortran past F77? The free Fortran 95 compiler
called g95 http://www.g95.org is available.



> Getting a python package working usually amounts to an install
command
> to the OS and an import command to the interpreter. Then you can get
> down to work. Getting a Fortran package working involves not only an
> endless dance with obscure compiler flags and library links, but then
a
> set of workarounds for codes that produce expected results on one
> compiler and compile failures or even different results on another.

If one writes standard-conforming code it does not. At least with
Fortran one has multiple independent implementations of an ISO
standardized language, about 10 each on Intel Windows or Linux, and 4
for Mac OS X. Links are at
http://dmoz.org/Computers/Programming/Languages/Fortran/Compilers/ . If
one Fortran compiler leaks memory when multiplying matrices, one can
use another. If Python Numarray does, the only alternative I know of is
Numeric, which is no longer supported according to
http://www.pfdubois.com/numpy/ . I have found it extremely useful to
work with multiple compilers and compiler options. A good compiler such
as Lahey/Fujitsu has debugging options that aid programmer productivity
by finding bugs, both at compile and run time, at some cost in speed. I
gave a few examples in a previous thread. The existence of such
compilers refutes your assertion that Fortran programmers think only
machine time is important.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fortran pros and cons (was Re: Coding style article with interesting section on white space)

[beliavsky]

Michael Tobis wrote:
> [EMAIL PROTECTED] wrote:
> > Michael Tobis wrote:
>
> > Fortran 90/95 is more expressive than Fortran 77 in many ways, as
> > described in ...
> > http://www.nr.com/CiP97.pdf .
> >
>
> > ... expresses more science per
> > line of code and per programming workday.
>
> The example shown on p 10 illustrates a shorter piece of code in f90
> than in f77, but it is not obviously more expressive or less complex.
> Arguably the f77 code is easier to write and maintain, even though it
> has more linefeeds in it, so I find the example far from compelling.

Ok, here are some simple examples of the greater expressiveness of
Fortran 95 compared to F77 or C for calculations involving arrays.

(1) To compute the sum of squares for each column of a matrix of the
positive elements, one can write in F90 just

isum = sum(imat**2,dim=1,mask=imat>0)

compared to

do j=1,ncol
isum(j) = 0
do i=1,nrows
if (imat(i,j) > 0) isum(j) = isum(j) + imat(i,j)**2
end do
end do

I think there is a similar Numeric Python one-liner using the sum and
compress functions. Array operations are not revolutionary (APL had
them in 1960s), but they are faster to write and later read.

(2) Suppose x and y are matrices of the same size and one wants to set
each element y(i,j) = f(x(i,j)) for some elemental (no side-effects)
function f. In Fortran 95, one can just write

y = f(x)

compared to

do j=1,ncol
do i=1,nrow
y(i,j) = f(x(i,j))
end do
end do

The ufunc of Numeric Python and the map of basic Python offer similar
functionality.

With Fortran 95 one can code numerical algorithms involving arrays in a
high-level manner similar to Python with Numeric/Numarray or Matlab,
while retaining the advantages (better performance, stand-alone
executables) and disadvantages (explicit variable declarations, no
scripting ability) of a compiled language with static typing. That's
all I am claiming.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How do you do arrays

[beliavsky]

If you want do numerical calculations with vectors and matrices, you
should probably use the Numarray module. Python's built-in lists are
not intended for heavy numerical computations. They are more flexible
than the arrays in languages like C and Fortran in that they can store
elements of different types. One can write, for example,
x = ["dog",1,2.3] .

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How do you do arrays

[beliavsky]

wes weston wrote:
> Thomas,
> If you were allowed to do what you're doing, the
> list first element would be getting skipped as "index"
> is always > 0. The thing is, you don't want the "index"
> var at all for adding to the list; just do jMatrix.append(k).
> You can iterate over the list with
> for x in jMatrix:
> print x
>
> Is it basic that indexes from 1 vs. 0? 'just about
> completely forgotten basic.
> wes

I think most versions of Basic have arrays that by default start with
1, as did their ancestor, Fortran, although other lower bounds can be
specified. VB.NET, Microsoft's successor to Visual Basic, requires
arrays to start with zero.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is there a market for python developers?

[beliavsky]

Mabon Dane wrote:
> I am new to python and took my first attempts at working with this
> language today.  Is there a market for people who work with Python?

You can Google this newsgroup for "[EMAIL PROTECTED] jobs" to find two
messages I posted with statistics.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python versus Perl ?

[beliavsky]

Jorgen Grahn wrote:

> >  I've read that many people prefer Python and that it is better
than
> > Perl. However, I want to ask a few other questions.
>
> I could go on and on, but this essay by Eric Raymond says it better:
>
>   http://www.linuxjournal.com/article/3882

His survey of programming languages in "The Art of Unix Programming",
available at
http://www.catb.org/~esr/writings/taoup/html/languageschapter.html , is
interesting (and biased). Raymond evaluates C, C++, Shell, Perl, Tcl,
Python, Java, and Emacs Lisp.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: declarations summary

[beliavsky]

Alex Martelli wrote:

> > socks off yet again, but I can't see counting on it. So the
successor
> > to Fortran (presuming it isn't C++, which I do presume) may be
> > influenced by Python, but probably it won't be Python.
>
> You appear to assume that Fortran is dead, or dying, or is gonna die
> soon.  I assume Mr. Beliavski will do a great job of jumping on you
for
> this, so I can save the effort of doing do myself;-).

Everyone needs a purpose in life :). I hope that Fortran 2003 and
future versions will be the successors of traditional Fortran, but I
may well be disappointed.

Many scientists and engineers do not have the motivation, the time, or
even the ability to master C++, generally acknowledged to be a language
for professional programmers. When performance is not paramount, they
can use Python (with Numarray or Numeric) and other array languages
like Matlab/Octave/Scilab as reasonable alternatives to Fortran.
Despite its high cost for non-students, Matlab is enormously popular
among engineers.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is Python as capable as Perl for sysadmin work?

[beliavsky]

John M. Gabriele wrote:
> I recently posted this sort of question to the c.l.p.m but
> didn't get much of a response. I know a little Perl and a
> little Python, but master neither at the moment.
>
> I see that Python is a general purpose OO programming language
> that finds use among some system administrators, but my guess
> is that Perl is still more common in that area than Python.
>
> For sysadmin-related tasks, is Python as useful as Perl, or
> does it get clumsy when often dealing with the stuff admins
> deal with on a regular basis?

I'm a Windows user, not a Unix sysadmin, but I've noticed that
Cameron Laird has written several articles on Python for system
administration in Unix Review and Sys Admin magazine, for example
http://www.unixreview.com/documents/s=9083/sam0401d/ . Reading his
articles may help you decide if Python is a good fit for your work.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Loop in list.

[beliavsky]

Jim wrote:
> Wow!  All I wanted to do was write the equivalence
> of the Fortran statement:  Real*4 matrix(n,n).

If you are doing numerical linear algebra in Python, you should use the
Numeric or Numarray modules. With Numeric, the equivalent is just

from Numeric import zeros
matrix = zeros([n,n],Float)

-- 
http://mail.python.org/mailman/listinfo/python-list

exception handling for a function returning several values

[beliavsky]

If a function that normally returns N values raises an exception, what
should it return? N values of None seems reasonable to me, so I would
write code such as

def foo(x):
try:
   # code setting y and z
   return y,z
except:
   return None,None

y,z = foo(x)

If I try to use y or z inappropriately when they are None, the program
will stop. An alternative is to return an error flag in addition to y
and z from function foo and check the value of the error flag in the
calling program. This seems a bit awkward.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FS: O'Reilly Python Pocket Reference

[beliavsky]

I think a better place than this newsgroup to offer used Python books
for sale is Amazon or Ebay or Alibris.

-- 
http://mail.python.org/mailman/listinfo/python-list

naming convention for scalars, lists, dictionaries ...

[beliavsky]

Since Python does not have declarations, I wonder if people think it is
good to name function arguments according to the type of data structure
expected, with names like "xlist" or "xdict".

-- 
http://mail.python.org/mailman/listinfo/python-list

GOTO (was Re: Appeal for python developers)

[beliavsky]

Torsten Bronger wrote:
> Hallöchen!
>
> BOOGIEMAN <[EMAIL PROTECTED]> writes:
>
> > Please include "goto" command in future python realeses I know
> > that proffesional programers doesn't like to use it, but for me as
> > newbie it's too hard to get used replacing it with "while", "def"
> > or other commands
>
> Accordings to Stroustrup's C++ book, the only good reason for goto
> statements in a language is to have it in computer-generated code.
> I don't know whether programs generate Python, but I *think* that
> even there "goto" can be avoided very easily.

Goto is useful in breaking out of a nested loop and when there is a
clean-up section of a function that should be executed for various
error conditions.

In another newsgroup I once asked "who needs GOTO" and got some good
answers -- the thread can be found by Googling '[EMAIL PROTECTED]
"explicit GOTO"'. Goto's are less dangerous when they are in the
forward direction, to code appearing later.

--
http://mail.python.org/mailman/listinfo/python-list

Re: survey

[beliavsky]

Dave Zhu wrote:
> Hello All,
>
> Is there any survey on scripting languages? I would
> like to get information on several scripting languages
> including Python, Perl, Ruby, Tcl, etc.

The Language Shootout at http://shootout.alioth.debian.org/ has code
samples in many languages, both interpreted and compiled, including the
ones you mentioned. Don't trust the lines-of-code statistics, though --
the LOC measure is wrongly shown as zero for several codes, and comment
lines are counted, so that languages with programmers who use more
comments are penalized.

You can obtain the paper "Are Scripting Languages Any Good? A
Validation of Perl, Python, Rexx, and Tcl against C, C++, and Java." by
Prechelt at http://page.mi.fu-berlin.de/~prechelt/Biblio/ -- his answer
is "yes".

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: survey

[beliavsky]

[EMAIL PROTECTED] wrote:
> > The Language Shootout at http://shootout.alioth.debian.org/ has
code
> > samples in many languages, both interpreted and compiled, including
> the
> > ones you mentioned. Don't trust the lines-of-code statistics,
though
> --
> > the LOC measure is wrongly shown as zero for several codes, and
> comment
> > lines are counted, so that languages with programmers who use more
> > comments are penalized.
>
> afaik the LOC measure does not count comment lines - is there a
> specific example?

(this message is OT for c.l.py, sorry)

The "random Fortran Intel program" at
http://shootout.alioth.debian.org/benchmark.php?test=random&lang=ifc&id=0&sort=fullcpu
is said to have 40 lines, but excluding blank lines and comment lines
(those that start with "!") I count 22.

The "ackermann Fortran Intel program" at
http://shootout.alioth.debian.org/benchmark.php?test=ackermann&lang=ifc&id=0&sort=fullcpu
is wrongly said to have 0 lines.

There are other cases of these problems.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Who Knows of a Good Computational Physics Textbook?

[beliavsky]

There is some info on teaching computational physics at Rubin Landau's
site http://www.physics.orst.edu/~rubin/ .

Springer recently published the book "Python Scripting for
Computational Science" by Hans P. Langtangen .

Searching "computational physics" at Amazon returns some relevant
books.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Who Knows of a Good Computational Physics Textbook?

[beliavsky]

Sean Richards wrote:
> This may be of interest
>
> http://farside.ph.utexas.edu/teaching/329/lectures/lectures.html

The information at
http://farside.ph.utexas.edu/teaching/329/lectures/node7.html about
scientific programming languages is out of date, since g95
http://www.g95.org is a free Fortran 95 compiler for all platforms (and
is already used in some courses), and Intel Fortran 95 for Linux is
free for non-commercial use.

-- 
http://mail.python.org/mailman/listinfo/python-list

PyGoogle featured on Google Code

[beliavsky]

Google has started a site Google Code http://code.google.com/ to
showcase Open Source software, and the first featured project is
PyGoogle, a Python module wrapper for the Google Web APIs. Also
mentioned is goopy/functional, a library that brings functional
language attributes to Python.

-- 
http://mail.python.org/mailman/listinfo/python-list

Python tutorial for LinuxQuestions.org?

[beliavsky]

I think a short Python tutorial at LinuxQuestions.org
http://www.linuxquestions.org/questions/answers.php?action=viewcat&catid=4
would be a good way of introducing Python to new programmers. There are
currently tutorials there for C, C++, and Java that have been viewed
thousands of times. Of course, Python tutorials exist on the Internet ,
but many prospective programmers may not realize the language exists. I
am better to qualified to write a tutorial for another language :).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting the word to conventional programmers

[beliavsky]

Advocates of languages and programming methodologies sometimes compare
the current version of their favorite language to an old version of
their disfavored language, resulting in skewed comparisons. For
example, Conway writes

"Interpreted languages do two things much better than compiled
languages.

Firstly, they provide more sophisticated programming tools and support
for more advanced programming techniques. For example, Perl provides
hashed look-up tables and arbitrary-length arrays as core data types. C
doesn't even have a proper string type. Likewise, Perl's data sorting
facilities are integrated into the language, so the sorting criteria
are directly programmable.

Having all the basic tools of programming (i.e. high-level data types
and common algorithms) built into the language, rather than having to
build them yourself, means that you need to write less code to solve a
given problem."

I think most of the advanced programming techniques he mentions are
part of the C++ Standard Library.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: looking for programmer

[beliavsky]

Peter Tyler wrote:
> Hi There,
>I'm looking for someone to write some wx/python code on a small
job, but want
> to avoid a spam invasion.
> I was thinking of setting up a temp yahoo account for people to
respond to.
> Is this the right way of going about this, or is there somewhere else
I should
> be looking?
>  Thanks
>Peter.

If the work can be done off-site, you can solicit bids on a site such
as RentACoder.com . It is possible to specify Python as the language to
be used, and many Python projects have been arranged there.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting the word to conventional programmers

[beliavsky]

Terry Reedy wrote:
> "Cameron Laird" <[EMAIL PROTECTED]> wrote in message
>
news:[EMAIL PROTECTED]
> > *DevSource* profiles "The State of the Scripting Universe" in
> > http://www.devsource.com/article2/0,1759,1778141,00.asp >.
>
> Interesting quote from Guido: "If the same effort were poured into
speeding
> up Python as Sun devoted to Java, Python would be better than Java in
every
> respect."

Maybe companies such as Intel, IBM, and Sun would devote resources to
optimizing Python on their hardware if the language had an ISO
standard, as do C, C++, and Fortran, and were less of a moving target.
OTOH, that could slow the development of the language.

I have wondered why the "dynamic" languages such as Perl and Python
tend not to have ISO standards.

-- 
http://mail.python.org/mailman/listinfo/python-list

Use informative subject lines! (was Re: Dumb*ss newbie Q)

[beliavsky]

A subject line should say what the message is about, for example

"Create HTML tag using objects (newbie Q)"

and enable people who are not interested in or knowledgable about a
topic to skip it, while grabbing the attention of people who are
knowledgable/interested.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: author index for Python Cookbook 2?

[beliavsky]

Premshree Pillai wrote:
> There's an index here:
http://harvestman.freezope.org/cookbook/creds.html

That lists the authors. Where is a list of the recipes?

-- 
http://mail.python.org/mailman/listinfo/python-list

TOC of Python Cookbook now online (was Re: author index for Python Cookbook 2?)

[beliavsky]

[EMAIL PROTECTED] wrote:
> Premshree Pillai wrote:
> > There's an index here:
> http://harvestman.freezope.org/cookbook/creds.html
>
> That lists the authors. Where is a list of the recipes?

I emailed the O'Reilly webmaster, and the table of contents are now
online at http://www.oreilly.com/catalog/pythoncook2/toc.html and also
listed below.

Table of Contents
Preface
1. Text
   1.1 Processing a String One Character at a Time
   1.2 Converting Between Characters and Numeric Codes
   1.3 Testing Whether an Object Is String-like
   1.4 Aligning Strings
   1.5 Trimming Space from the Ends of a String
   1.6 Combining Strings
   1.7 Reversing a String by Words or Characters
   1.8 Checking Whether a String Contains a Set of Characters
   1.9 Simplifying Usage of Strings' translate Method
   1.10 Filtering a String for a Set of Characters
   1.11 Checking Whether a String Is Text or Binary
   1.12 Controlling Case
   1.13 Accessing Substrings
   1.14 Changing the Indentation of a Multiline String
   1.15 Expanding and Compressing Tabs
   1.16 Interpolating Variables in a String
   1.17 Interpolating Variables in a String in Python 2.4
   1.18 Replacing Multiple Patterns in a Single Pass
   1.19 Checking a String for Any of Multiple Endings
   1.20 Handling International Text with Unicode
   1.21 Converting Between Unicode and Plain Strings
   1.22 Printing Unicode Characters to Standard Output
   1.23 Encoding Unicode Data for XML and HTML
   1.24 Making Some Strings Case-Insensitive
   1.25 Converting HTML Documents to Text on a Unix Terminal
2. Files
   2.1 Reading from a File
   2.2 Writing to a File
   2.3 Searching and Replacing Text in a File
   2.4 Reading a Specific Line from a File
   2.5 Counting Lines in a File
   2.6 Processing Every Word in a File
   2.7 Using Random-Access Input/Output
   2.8 Updating a Random-Access File
   2.9 Reading Data from zip Files
   2.10 Handling a zip File Inside a String
   2.11 Archiving a Tree of Files into a Compressed tar File
   2.12 Sending Binary Data to Standard Output Under Windows
   2.13 Using a C++-like iostream Syntax
   2.14 Rewinding an Input File to the Beginning
   2.15 Adapting a File-like Object to a True File Object
   2.16 Walking Directory Trees
   2.17 Swapping One File Extension for AnotherThroughout a
Directory Tree
   2.18 Finding a File Given a Search Path
   2.19 Finding Files Given a Search Path and a Pattern
   2.20 Finding a File on the Python Search Path
   2.21 Dynamically Changing the Python Search Path
   2.22 Computing the Relative Path from One Directory to Another

   2.23 Reading an Unbuffered Character in a Cross-Platform Way
   2.24 Counting Pages of PDF Documents on Mac OS X
   2.25 Changing File Attributes on Windows
   2.26 Extracting Text from OpenOffice.org Documents
   2.27 Extracting Text from Microsoft Word Documents
   2.28 File Locking Using a Cross-Platform API
   2.29 Versioning Filenames
   2.30 Calculating CRC-64 Cyclic Redundancy Checks
3. Time and Money
   3.1 Calculating Yesterday and Tomorrow
   3.2 Finding Last Friday
   3.3 Calculating Time Periods in a Date Range
   3.4 Summing Durations of Songs
   3.5 Calculating the Number of Weekdays Between Two Dates
   3.6 Looking up Holidays Automatically
   3.7 Fuzzy Parsing of Dates
   3.8 Checking Whether Daylight Saving Time Is Currently in Effect

   3.9 Converting Time Zones
   3.10 Running a Command Repeatedly
   3.11 Scheduling Commands
   3.12 Doing Decimal Arithmetic
   3.13 Formatting Decimals as Currency
   3.14 Using Python as a Simple Adding Machine
   3.15 Checking a Credit Card Checksum
   3.16 Watching Foreign Exchange Rates
4. Python Shortcuts
   4.1 Copying an Object
   4.2 Constructing Lists with List Comprehensions
   4.3 Returning an Element of a List If It Exists
   4.4 Looping over Items and Their Indices in a Sequence
   4.5 Creating Lists of Lists Without Sharing References
   4.6 Flattening a Nested Sequence
   4.7 Removing or Reordering Columns in a List of Rows
   4.8 Transposing Two-Dimensional Arrays
   4.9 Getting a Value from a Dictionary
   4.10 Adding an Entry to a Dictionary
   4.11 Building a Dictionary Without Excessive Quoting
   4.12 Building a Dict from a List of Alternating Keys and Values

   4.13 Extracting a Subset of a Dictionary
   4.14 Inverting a Dictionary
   4.15 Associating Multiple Values with Each Key in a Dictionary

   4.16 Using a Dictionary to Dispatch Methods or Functions
   4.17 Finding Unions and Intersections of Dictionaries
   4.18 Collecting a Bunch of Named Items
   4.19 Assigning and Testing with One Statement
   4.20 Using printf in Python

Re: text analysis in python

[beliavsky]

The book "Text Processing in Python" by David Mertz, available online
at http://gnosis.cx/TPiP/ , may be helpful.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Symbol Referencing Error in Fortran 90

[beliavsky]

This message was also posted and replied to on comp.lang.fortran -- I
think it's presence here is an accident.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: TOC of Python Cookbook now online (was Re: author index for Python Cookbook 2?)

[beliavsky]

robin wrote:
> [EMAIL PROTECTED] wrote:
>
> >I emailed the O'Reilly webmaster, and the table of contents are now
> >online at http://www.oreilly.com/catalog/pythoncook2/toc.html and
also
> >listed below.
>
> Unfortunately there is no list of authors for the sections in the
> book. This is likely its only shortcoming!
>
> -- robin

I have found the site http://aspn.activestate.com/ASPN/Python/Cookbook/
, which has the code for 1142 recipes, with the names of authors
listed.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best editor?

[beliavsky]

ChinStrap wrote:
> When not using the interactive prompt, what are you using? I keep
> hearing everyone say Emacs, but I can't understand it at all. I keep
> trying to learn and understand why so many seem to like it because I
> can't understand customization even without going through a hundred
> menus that might contain the thing I am looking for (or I could go
> learn another language just to customize!).

Epsilon http://www.lugaru.com/ is a commercial Emacs-like editor with a
built-in Python mode and will automatically treat .py files as being
Python. No fiddling is required. It works well, and I spend many of my
waking hours in front of an Epsilon (even created a Fortran mode :)). I
think Epsilon is used more on Windows than Linux/Unix, where Emacs and
XEmacs have existed for a long time, but an Epsilon license contains
binaries for Linux and other Unices as well.

XEmacs/Emacs frustrate me, for example constantly asking if I want to
enable a "recursive mini-buffer", which I have no clue about or
interest in. Epsilon is a well-done Emacs IMO.

A key benefit of Emacs-like editors, including Epsilon, is that one can
run the shell (cmd.exe prompt on Windows, bash/csh/ksh on Unix) from
within the editor. One can fill the entire screen with an Emacs, split
it into buffers for source codes and a shell, and live happily ever
after :). Standard output is not lost but can be retrieved just by
scrolling up in the editor. I am addicted to running a shell within an
Emacs-like editor.

Of course there are many good editors -- don't feel obligated to use
Emacs if you are happy and productive with something else.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UselessPython 2.0

[beliavsky]

Nice idea for a site, but I suggest renaming it to something like
FunPython.com . My guess from reading the subject of your message was
that you hated Python! Besides, "fun" is shorter than "useless" and is
therefore more Pythonic :).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming Language for Systems Administrator

[beliavsky]

Ville Vainio wrote:

> If you don't need to edit already existing system scripts, you don't
> really need to know bash scripting. For debugging purposes, it's easy
> to see what commands the script executes to perform a task.
>
> You just need to know about `backticks` and $ENV_VARS, but that's
more
> general Unix knowledge than actual shell scripting.
>
> So IMHO learning bash scripting might be a waste of time, and it
> should be learnt 'as you go' - i.e. if/when you eventually bump into
a
> problem where you need to be able to do bash scripting. There's the
> 'Unix romantic' movement that still thinks shell scripts are a good
> idea, but this is my .02EUR to point out that not everyone agrees
with
> them.

The simplest script is just a set of commands one could run from the
command line. One step above is learning how to pass arguments (for
cmd.exe in Windows, they are just %1, %2, etc.) and set variables. I
think every computer user, not just system administrators, show know
this much about the shell language of his OS, regardless of whether
it's Windows, Unix, or something else. On Windows I often see people
"mousing around" instead of getting things done faster from the command
line.

I actually like the Windows cmd language (it's an acquired taste), but
I have read it is going away in Windows Longhorn (WH). That's an
argument for writing more complicated scripts in Python. WH is supposed
to get a much better shell, called Monad, inspired by the philosophy of
Gottfried Wilhelm Leibniz :).

Between a low-level shell scripting language and a higher-level
language like Python, and intermediate level language such as Rexx
could be considered. Many IBM people swear by it.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming Language for Systems Administrator

[beliavsky]

Brian van den Broek wrote:
> [EMAIL PROTECTED] said unto the world upon 2005-04-12 08:11:
>
> 
>
> > I actually like the Windows cmd language (it's an acquired taste),
but
> > I have read it is going away in Windows Longhorn (WH). That's an
> > argument for writing more complicated scripts in Python. WH is
supposed
> > to get a much better shell, called Monad, inspired by the
philosophy of
> > Gottfried Wilhelm Leibniz :).
>
> Hi all,
>
> this is the first I've heard of Monad.
>
> Leibniz characterized his monads as the fundamental building blocks
of
> nature, insusceptible of change from the outside, and as
"windowless".
>
> So, if the account of MS's plans is true, it would seem to indicate a

> combination of arrogance, honesty, and ignorance. (I leave it to you
> to decide which part, if any, of this triad, is surprising.)
>
> Best to all,
>
> Brian vdB

I was joking about Leibniz, but from the Wikipedia article
http://en.wikipedia.org/wiki/MSH_(shell) it appears that the codename
of the new Microsft shell was in small part inspired by the philosophy
of Leibniz:

"Central concepts
The system's codename comes from Gottfried Leibniz's "Monadology", a
philosophy which says that everything is a composition of fundamental
elements called 'Monads', which are all integrated together in
'pre-established harmony'. Similarly, the focus of MSH is on
composition of complex tasks from a series of components. In this case,
the components are special programs called commandlets (or cmdlets),
which are .NET classes designed to use the features of the environment.
The key difference between the Unix approach and the MSH one is that
rather than creating a "pipeline" based on textual input and output,
MSH passes data between the various commandlets as arbitrary objects.

If accessed individually from the command-line, a commandlet's output
will automatically be converted into text, but if its output is to be
used by another commandlet, it will be converted into whatever form of
object is most appropriate for that commandlet's input. This has the
advantage of eliminating the need for the many text-processing
utilities which are common in Unix pipelines, such as grep and awk, as
well as allowing things to be combined interactively, or in a scripting
environment, which would otherwise require a more complex programming
language. For instance, a listing of processes will consist not of text
describing them, but objects representing them, so that methods can be
called on those objects without explicit reference to any outside
structure or library.

MSH is part of an overall strategy within Longhorn to treat all parts
of the OS as .NET objects, and thus allow the user greater flexibility
over how they are used. This is aimed to make previously complex
interactions manageable within the bounds of frameworks such as MSH;
for example, Longhorn's registry can be exported as though it were a
filesystem, and navigated by treating it as a hierarchy of files and
directories."

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: preallocate list

[beliavsky]

Jim wrote:
> Hi all
>
> Is this the best way to preallocate a list of integers?
> listName = range(0,length)

For serious numerical work you should use Numeric or Numarray, as
others suggested. When I do allocate lists the initial values 0:n-1 are
rarely what I want, so I use

ivec = n*[None]

so that if I use a list element before intializing it, for example

ivec[0] += 1

I get an error message

  File "xxnone.py", line 2, in ?
ivec[0] += 1
TypeError: unsupported operand type(s) for +=: 'NoneType' and 'int'

This is in the same spirit as Python's (welcome) termination of a
program when one tries to use an uninitalized scalar variable.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: Python 2.3.2 for PalmOS available

[beliavsky]

What are the potential applications of Python on PalmOS? Just curious.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why Python does *SLICING* the way it does??

[beliavsky]

Terry Hancock wrote:



> So I like Python's slicing because it "bites *less*" than intervals
in C or Fortran.

I disagree. Programming languages should not needlessly surprise
people, and a newbie to Python probably expects that x[1:3] =
[x[1],x[2],x[3]] . Array-oriented languages, such as Fortran 90/95,
Matlab/Octave/Scilab, and S-Plus/R do not follow the Python convention,
and I don't know of Fortran or R programmers who complain (don't follow
Matlab enough to say). There are Python programmers, such as the OP and
me, who don't like the Python convention. What languages besides Python
use the Python slicing convention?

Along the same lines, I think the REQUIREMENT that x[0] rather than
x[1] be the first element of list x is a mistake. At least the
programmer should have a choice, as in Fortran or VBA. In C starting at
0 may be justified because of the connection between array subscripting
and pointer arithmetic, but Python is a higher-level language where
such considerations are less relevant.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Define Constants

[beliavsky]

A "recipe" for "Constants in Python" by Alex Martelli is at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65207 .

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why Python does *SLICING* the way it does??

[beliavsky]

Dan Bishop wrote:
> Antoon Pardon wrote:



> > Like users have a choice in how long they make a list, they
> > should have a choice where the indexes start. (And that
> > shouldn't be limited to 0 and 1).
>
> Suppose you could.  Then what should
>
> ([3, 1, 4] indexbase 0) + ([1, 5, 9] indexbase 4)
>
> equal?

Assuming the + sign means concatenate (as it does for Python lists)
rather than add (as it does for Numeric or Numarray arrays), it would
be

([3,1,4,1,5,9] indexbase 0)

since 0 would still be the default indexbase. If the user wanted a
1-based list as a result, he would use an expression such as

(([3, 1, 4] indexbase 0) + ([1, 5, 9] indexbase 4) indexbase 1)

If + means add, the result would be

([4,6,13] indexbase 0) .

Adding arrays makes sense if they have the same number of elements --
they do not need to have the same indices.

I rarely see problems caused by flexible lower array bounds mentioned
in comp.lang.fortran .

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can .py be complied?

[beliavsky]

IMO the fact that so many people ask

"How can I create executables in Python on Windows"

indicates that standard "batteries included" Windows Python
distribution is missing a vital battery. There are tools such as
py2exe, but this functionality should be built-in, so that a newbie to
Python can just download it, type

python -o foo.exe foo.py

at the command line, and get an executable, without any further effort.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OOP

[beliavsky]

[EMAIL PROTECTED] wrote:
> Hey yall,
> I'm new to Python and I love it. Now I can get most of the topics
> covered with the Python tutorials I've read but the one thats just
> stumping me is Object Orientation. I can't get the grasp of it. Does
> anyone know of a good resource that could possibly put things in
focus
> for me?

Maybe Part VI, "Classes and OOP", of the book "Learning Python", 2nd
edition, by Lutz and Ascher. Both the motivation for OOP and its
implementation in Python are discussed, in about 100 pages.

-- 
http://mail.python.org/mailman/listinfo/python-list

get file modification time in mm/dd/yyyy format?

[beliavsky]

Using Python 2.4 on Windows, for me the command

print os.stat("temp.txt")[stat.ST_MTIME]

gives

1115478343 ,

which is "seconds since the epoch". How can I get the modification time
in a format such as

05/07/2005  11:05 AM

as in Windows with the dir command? Ideal would be a tuple of 6 values,
(year,month,day,hour,minute,second). Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie : checking semantics

[beliavsky]

[EMAIL PROTECTED] wrote:



> 2. Trust me (and other Python programmers most likely would agree)
this
> type of error happens much more seldom then newbies (especially
coming
> from strongly typed languages) imagine while adjusting to the
language.
>
> 3. Python advantages "overpower" drawbacks 10 to 1.
>
> 4. Most likely you never used Fortran :)

The Newbie is outnumbered on this issue in comp.lang.python, but he is
not alone :). In Fortran 77 and earlier versions, many run-time errors
resulted from

(1) misspelling a variable name, since variable declarations were not
required and IMPLICIT NONE (forcing declarations) was standardized only
in Fortran 90.

(2) passing variables of the wrong type (real instead of double
precision, scalar instead of array, etc.) to a procedure -- this could
not be checked at compile-time if the procedure and caller were
compiled separately and then linked. Fortran 90 added MODULEs, partly
to fix this.

I programmed in Fortran 77 for years before using Fortran 90 and find
that in the latter version I am more productive, since a program that
compiled was much more likely to be correct. I think many Fortranners
concur.

ANSI C 89 provides for more static type checking than the original K&R
C, and I think most C programmers appreciate this.

Looking at how other programming languages evolved, based on hard-won
experience, Python looks like a move in the opposite direction -- less
"compile-time" checking.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: first release of PyPy

[beliavsky]

Shane Hathaway wrote:



> > Please could somebody explain to us non-CS people why PyPy could
> > have speed features CPython can't have?
>
> The idea is to shift more of the responsibility to optimize code from
> the human to the computer.  Since C code is at a low level, the
computer
> can only infer low level intent and thus perform low level
> optimizations.  Humans optimize C by making thousands of
speed-oriented
> decisions directly in the code.  Python code is at a much higher
level,
> which should enable the computer to discover more of the programmer's
> intent and perform deep optimizations.
>
> In the end, the computer's automated optimization could turn out
better
> than a human's manual optimization.  Thus, by expressing the Python
> interpreter in a high level manner, PyPy is a first step toward deep
> optimizations that aren't possible to automate in C.

I am less optimistic but hope I am wrong :).

C++ is a higher level language than C, but it's not clear to me that
compilers are able to optimize C++ code using higher-level features
such as the Standard Library so that they run as fast as the equivalent
C code. OTOH, some C++ experts have advocated template metaprogramming
as a way of speeding up programs. I wonder how widely this technique is
used.

Fortran 95 is a considerably higher level language than Fortran 77, but
I get the impression from comp.lang.fortran that it is harder to
optimize. Fortran compilers compete in a performance-driven market, and
AFAIK they are written in C.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are OOP's Jargons and Complexities?

[beliavsky]

Thomas G. Marshall wrote:

> > I am not familiar with modern Fortran. Surely it at least has argument
> > prototyping by now?

Since the 1990 standard, if Fortran subroutines and functions are
placed in MODULEs, or if INTERFACEs are provided, the compiler checks
that procedures are called with the right types (int or float, scalar
or array, etc.) of arguments.

> There are some fortran advocates that pop into here now and again.  Frankly,
> I'm spooked by how far fortran seems to have come.  There is even OO support
> now.  OI.

Some Fortranners think the language has gotten too big and complicated,
sounding a bit like C programmers complaining about C++ (I don't mean
that pejoratively).

-- 
http://mail.python.org/mailman/listinfo/python-list

Python 2nd favorite language in Linux Journal poll

[beliavsky]

Linux Journal annually polls its readers on questions such as their
favorite programming language. In the 2005 poll, Python is 2nd, its
highest ranking ever. Below are the results by year. I wish that
rankings beyond the first 3 were available and that the number of votes
were shown. Nerds like numbers, not journalist blather :). I found this
data for earlier years by Googling

"linux journal  readers choice awards".

2005
1. C++
2. Python
3. PHP

2004
Favorite Programming Language
1. C
2. Perl
3. C++

Ah, favorite programming language-time for a flame war. A bit of a
shake-up this year: after being knocked out of first place last year, C
reclaims it this year and C++ drops to third. The P language in the top
three is Perl, while PHP slips to fourth place, closely followed by
Python. The voting was close this year, too; only 59 votes separated C
from C++.

2003
Favorite Programming Language
1. C++
2. C
3. PHP
Quick, everyone to your keyboard: the flame war begins in 5, 4, 3,
2In a reversal of last year's winner and runner-up, C++ moved into
first place in 2003 by a mere 23 votes. Perl, meanwhile, got kicked out
of the top three for the first time in the history of our awards.
Continuing the C theme, C# is the favorite write-in vote.

2002
Favorite Programming Language
1. C
2. C++
3. Perl

C++ kicked Perl out of the second-favorite position this year, and only
17 votes kept C++ out of the top spot. In its first year on the
``official'' list, Kylix/Object Pascal came in fourth. Following that
was a close vote spread between PHP, Java and Python, in that order.
One quite reasonable voter wrote in that he uses ``whichever is best
for the project''. And to the voter who felt bad about preferring bash
shell scripting, don't worry, you're not alone.

2001
Favorite Programming Language
1. C
2. Perl
3. C++

Here's another category where we took your advice from last year and
split C/C++ into separate categories because, hey, they're not the
same. Java and PHP finish out the top five, with Python just missing
out by 15 votes. Kylix/Object Pascal had a strong write-in showing,
over 200 votes.

2000
1. C/C++
2. Perl
3. Java

``Plain C (without the ++).''

The perennial C/C++ wins 40% of your votes this year. To everyone who
took the time to remind us that C and C++ are not the same language, we
hear you loud and clear. Second and third place go to Perl and Java,
while Python continues to expand its fan base by claiming 8%.

1999
1. C/C++
2. Perl
3. Java

``Something wants to make me vote for Logo... but I'll spare you. :)''

The old UNIX standard--the closest thing we have to a cross-platform
assembler--wins nearly half the vote at 49.4%. We'll have to split C
and C++ next year; we received countless ``I hate C++'' comments, a
sentiment shared by nearly everyone who voted. Perl had an excellent
showing, with 20.6% of the vote, compared to the up-and-coming Python
which scored 4%. At 9.5%, Java appears to have become rather popular,
and a concerted effort from PHP enthusiasts managed to score it 4.6%.
Emacs (meaning ELisp, probably) received a large number of write-ins.
Doesn't anyone use assembly code anymore?

1998
1. Perl
2. Tcl/Tk

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2nd favorite language in Linux Journal poll

[beliavsky]

beza1e1 wrote:
> Hm, you didn't include a link and my google did not find the final
> results.

I could not find a link, but the results appear on page 88 of the
November 2005 issue of Linux Journal.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: NEWBIE

[beliavsky]

brenden wrote:
> hey everyonei'm new to all this programming and all this stuff and
> i just wanted to learn how to do it...
>
> does anyone think they can teach me how to work with python?

Don't waste readers' time with such vague and broad requests. Instead,
post a specific question, for example showing a small fragment of
Python code that does not work as you expect. Or ask how to do XYZ in
Python, if you are unable to find the answer using Google.

"Newbie" by itself is always a bad subject line. Having a specific
question should help you form a better title for your message.

There is a mailing list for those learning Python at
http://mail.python.org/mailman/listinfo/tutor , but even there, you
will need to ask more specific questions.

-- 
http://mail.python.org/mailman/listinfo/python-list

why import, reload, import again?

[beliavsky]

Near the beginning of file test_matrix.py from scipy are the lines

import scipy.base
reload(scipy.base)
from scipy.base import *
del sys.path[0]

Could someone please explain why the first two lines were included? A
similar script I wrote works fine without them. Also, what is the
purpose of the "del" line? (I understand the mechanics of what "del"
does.) The scipy developers are skilled Python programmers, so I am
trying to understand the idioms used in their codes.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Developers Handbook

[beliavsky]

wooks wrote:
> I thought that posting a link that contained the word ebay and a
> subject title of Python Developers Handbook conveyed all the relevant
> information and didn't want to patronise the NG.
>
> I have had 110 hits on the item but seem to have upset 3 people.

This statement shows a misunderstanding of Usenet. Maybe the majority
of comp.lang.python readers agree with Terry Reedy but did not want to
clog the newsgroup with ditto messages.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What language to manipulate text files

[beliavsky]

ross wrote:
> Roose wrote:
> > Why do people keep asking what language to use for certain things in the
> > Python newsgroup?  Obviously the answer is going to biased.
> >
> > Not that it's a bad thing because I love Python, but it doesn't make sense
> > if you honestly want an objective opinion.
> >
> > R
>
> What usenet group is it best to ask in then?
> Is there one where people have good knowledge of many scripting
> languages?

"What programming language is best for x" questions can be asked in
comp.programming and/or comp.lang.misc , and possibly in a
domain-specific newsgroup if it exists, for example
sci.math.num-analysis if x = scientific computing. The resulting
debates contain both heat and light :).

-- 
http://mail.python.org/mailman/listinfo/python-list

article on PyNSol in CISE

[beliavsky]

The July/August 2005 issue of Computing in Science & Engineering has an
article by Michael Tobis about PyNSol (slides from the talk at
http://geosci.uchicago.edu/~tobis/PS0/PS3.html ). It appears to be a
code generation tool that takes a few equations specified by the user
and translates them to Python code using Numarray. The author says the
next choice for PyNSol's code generation target will be Fortran 77 -- I
think Fortran 95 would be preferable for readability and conciseness.
The article can be purchased from
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/cs/&toc=comp/mags/cs/2005/04/c4toc.xml&DOI=10.1109/MCSE.2005.78
.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python, mysql, floating point values question

[beliavsky]

Dennis Lee Bieber wrote:

>   Considering how often this has come up, I've sort of lost faith
> in CS programs at colleges. Now, this might be an unfair statement as I
> don't know if any of those bringing up the question ever had college CS
> courses... But the fluff of floating point data was something I vaguely
> recall had been covered in my second FORTRAN class [1976-77; I ran
> FORTRAN, Advanced FORTRAN, and Assembly in my first year] (since COBOL
> used packed decimal, it wasn't a candidate for the behavior -- not
> problem, as it is not erroneous behavior, just something one needs to
> learn about).
>
>   A book that may be out of print "Real Numbers Made Real" (hope I
> recalled the name) covers some of this.

Almost -- the book is "Real Computing Made Real: Preventing Errors in
Scientific and Engineering Calculations", by Forman S. Acton

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FORTRAN like formatting

[beliavsky]

Dennis Lee Bieber wrote:

> > On 7/8/05, Einstein, Daniel R <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Hi,
> > >
> > > Sorry for this, but I need to write ASCII from my Python to be read by
> > > FORTRAN and the formatting is very important. Is there any way of doing
> > > anything like:
> > >
> > > write(*,'(3(" ",1pe20.12))') (variable)
> > >
>
>   Which Fortran compiler? I know VMS Fortran was very friendly,
> when specifying "blanks not significant" or something like that... To
> read three floating numbers (regardless of format) merely required
> something like:
>
>   read(*, '(bn,3f)') a, b, c
>
> (or 'bs' for blanks significant -- I forget which one enabled free
> format input processing)

Fortran 77 and later versions have "list-directed" I/O, so the OP could
simply write

read (inunit,*) a,b,c

if the numbers in his input file are separated by spaces or commas. An
online reference is
http://docs.hp.com/cgi-bin/doc3k/B3150190022.12120/9 .

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python advocacy in scientific computation

[beliavsky]

I have posted your essay in a thread "Python for Fortran programmers"
in comp.lang.fortran since it is written in part for a Fortran
audience, and since you are more likely to get critical (but hopefully
constructive) comments there.

-- 
http://mail.python.org/mailman/listinfo/python-list

use SciPy with Python 2.4.1?

[beliavsky]

Is SciPy usable with Python 2.4.1? At http://www.scipy.org/download/ it
says that 2.3.3 is recommended, and I don't see a binary for 2.4.1.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Robust statistics and optimmization from Python

[beliavsky]

Robert Kern wrote:



> If you find suitable
> FORTRAN or C code that implements a particular "robust" algorithm, it
> can probably wrapped for scipy relatively easily.

An alternative would be to call R (a free statistical package) from
Python, using something like the R/SPlus - Python Interface at
http://www.omegahat.org/RSPython/ . Many statistical algorithms,
including those for robust statistics, have been implemented in R,
usually by wrapping C or Fortran 77 code.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: First release of Shed Skin, a Python-to-C++ compiler.

[beliavsky]

A.B., Khalid wrote:
> Mark Dufour wrote:
> > After nine months of hard work, I am proud to introduce my baby to the
> > world: an experimental Python-to-C++ compiler.
>
> Good work.
>
> I have good news and bad news.
>
> First the good news: ShedSkin (SS) more or less works on Windows. After
> patching gc6.5 for MinGW, building it, and testing it on WinXP with
> some succuess, and after patching my local copy of SS, I can get the
> test.py to compile from Python to C++, and it seems that I can get
> almost all the unit tests in unit.py to pass.

I am reluctant to attempt an arduous installation on Windows, but if
Mr. Dufour or someone else could create a web site that would let you
paste in Python code and see a C++ translation, I think this would
expand the user base. Alternatively, a Windows executable would be
nice.

-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: PyTrilinos (wrapper for parallel linear algebra)

[beliavsky]

PyTrilinos is a Python wrapper for the Trilinos linear algebra library.
It is described at
http://software.sandia.gov/trilinos/packages/pytrilinos/index.html and
in more detail in the PDF file at that site.

It was just announced on NA Digest. I have not tried it myself. Here
are some quotes from the Trilinos site.

"The Trilinos Project is an effort to develop and implement robust
parallel algorithms using modern object-oriented software design, while
still leveraging the value of established numerical libraries such as
PETSc, Aztec, the BLAS and LAPACK. It emphasizes abstract interfaces
for maximum flexibility of component interchanging, and provides a
full-featured set of concrete classes that implement all abstract
interfaces."

...

"PyTrilinos is a set of Python wrappers for selected Trilinos packages.
This allows a python programmer to dynamically import Trilinos packages
into a python script or the python command-line interpreter, allowing
the creation and modification of Trilinos objects and the execution of
Trilinos algorithms, without the need to constantly recompile."

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scipy for python 2.4 on windows

[beliavsky]

Z.L. wrote:
> I am a newbie to python, and have not so much experiences on package
> installation and related issues. I am looking for Scipy binaries for
> python 2.4 on windows.

Please see the recent thread "use SciPy with Python 2.4.1?" for
discussion of this.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what has python added to programming languages? (lets be esoteric, shall we ; )

[beliavsky]

Michael Tobis wrote:
> Although somewhat more elegant, Python slices follow Matlab's slice
> notation. In simpler cases they are identical.
>
> mt

I think in Matlab, as in Fortran 90, i:j refers to the elements from i
up to and including j, unlike Python, where j is excluded. Another
language with slicing is S, implemented in S-Plus and R. It follows the
same convention as Fortran.

The languages treat negative subscripts of lists and arrays
differently. In Fortran, since lower bounds of arrays can be negative,
a negative subscript has no special meaning. In S, where arrays start
with element 1, a negative subscript means that the absolute value of
the subscript is excluded, so that if array x has three elements, x[-2]
refers to (x[1],x[3]). In Python, negative indices "wraparound".

-- 
http://mail.python.org/mailman/listinfo/python-list

search file for tabs

[beliavsky]

The following code to search a file for tabs does not work, at least on
Windows XP. Could someone please tell me what's wrong? Thanks.

xfile = "file_with_tabs.txt"
for text in open(xfile,"r"):
text = text.strip()
if ("\t" in text):
print text

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: search file for tabs

[beliavsky]

Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > The following code to search a file for tabs does not work, at least on
> > Windows XP. Could someone please tell me what's wrong? Thanks.
> >
> > xfile = "file_with_tabs.txt"
> > for text in open(xfile,"r"):
> > text = text.strip()
> > if ("\t" in text):
> > print text
>
> since you're stripping away all leading and trailing whitespace from each
> line, you'll only find lines that have tabs "in the middle".
>
> (your code is only five lines long.  don't you think you could have double-
> checked each line a couple of times, asking yourself "what exactly is this
> line doing", in less time than it took you to compose the mail ?)

Both your specific and general suggestions are correct. Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list