Python 2.2.1 Released 19
An Anonymous Coward writes "It appears that the latest version of Python has been released. "We are pleased to announce the release of Python 2.2.1, on April 10, 2002. This is a bug-fix release for Python 2.2 and supersedes the 2.2 release." As far as what's new, it says,"This being a bug-fix release, there have been no exciting new features implemented since 2.2 -- just heaps of fixes.""
Yay for the Snake (Score:1, Redundant)
icons, /.?? (Score:2, Interesting)
Re:icons, /.?? (Score:2)
Perhaps Python Puzzles People?
I wonder....... (Score:1)
Why python? (Score:3, Interesting)
From a high level view, what makes python great? Where is python one of the best tools for the job? What are its strengths, and where is it most often used?
Re:Why python? (Score:5, Informative)
The syntax is clean and easy for us mere humans to read. For instance, compare the two following bits of code (one in C++, the other in Python):
#include <iostream>
using std::cout;
using std::endl;
int main(int argc, char *argv[])
{
unsigned long int fact = 1, x = 1;
for (x = 1 ; x < 6 ; x++) fact *= x;
cout << x-- << " factorial = " << fact << endl;
return fact;
}
... So far it's pretty obvious to C++ programmers what you're doing, but to anyone who doesn't know C++, even an example this simple borders on meaningless gibberish. What does "#include" mean? What do those `::'s mean in the using statement? What's cout and why do I care? What's char *argv[], and why do some people write it as char **argv?
The Python version of this same program, though, is beautifully simple to read:
def factorial(num):
fact = 1
for x in range(1, num + 1):
fact = fact * x
print fact
return fact
if __name__=='__main__':
factorial(5)
The Python code, while similar in lines of code, is enormously clearer. If you're willing to write functional Python code, it's even better:
def factorial(num, passfwd):
if num == 0: print passfwd
else: factorial(num - 1, passfwd * num)
if __name__=='__main__':
factorial(5, 1)
As a C++ coder, you're familiar with C++'s Every Paradigm And The Kitchen Sink approach. C++ lets you use generic programming, procedural programming, OO programming--whatever you need to get the job done. Python is the exact same. The OO syntax is clean, terse and readable; operator overloading is straightforward; and as my above example shows, functional programming is easy within Python.
Unlike some other interpreted languages (coughcoughJavacough) which coerce you into solving every problem via their One True Way (OO, usually), Python lets you solve problems the way you want to solve them.
Python might not run everywhere, but it runs everywhere I'm interested in being. It's possible to write crossplatform code with C/C++ (especially if you write code intelligently), but there are enough hardware gotchas to make crossplatform code difficult.
Python is just plain fun.
Python can easily be extended via C/C++ code, and it can easily be embedded within C/C++ code as a scripting language. This can often make for extremely impressive rapid application development; write the app in Python, then profile it and widen out the bottlenecks by writing them in native code. Doing this, I've managed to get performance approaching that of native code without anywhere near the headaches of writing the entire thing in native code.
Much like Perl, the available libraries for Python are mind-boggling. Check 'em out.
PyQt, PyKDE, PyGTK, PyGNOME, and a Win32 Python modules are all actively maintained. There are even Python GUI libraries for BeOS.
... I use C++ a fair bit, and I love the language. C++ is probably my favorite "mainstream" language, even if it does have a learning curve like the Matterhorn. But even though I love C++, I love Python just as much.
Python is not a replacement for C/C++. It wasn't meant to be, either. But as an adjunct to C/C++, Python is magnificent.
Re:Why python? (Score:3, Informative)
Erk. The correct functional formulation of this problem is:
>>> def fact( n ):
... if n == 0:
... return 1
... else:
... return n * fact( n - 1 )
...
>>> fact( 5 )
120
Or, more succinctly (and more stack efficient):
>>> import operator
>>> def fact( n ):
... return reduce( operator.mul, range(1, n+1) )
...
>>> fact(5)
120
The above samples cut-n-pasted from a Python interactive session also show more clearly how a new user would learn the language. Like the Good Old Days of computers that booted straight to BASIC interpreters, Python allows you to experiment with programming by just typing fragments of code at the prompt and trying them out.
Re:Why python? (Score:2)
Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional.
The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.
The recursive version, for n = 998:
real 0m0.079s
user 0m0.060s
sys 0m0.020s
The reduce version, for n = 998:
real 0m0.108s
user 0m0.060s
sys 0m0.020s
Re:Why python? (Score:2)
I knew I'd get pulled-up for using the word "correct"
I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident.
Python doesn't optimise the tail recursion away, so the version you gave still eats stack. Given that you're not winning anything by being tail-recursive, you might as well go for the more standard mathematical form.
The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.
On the contrary, you'll see they both take exactly the same amount of time if you look more closely. The real value returned by time is a wall-clock figure, which doesn't represent the actual CPU time spent. The wall-clock figure will vary depending on what else the system was doing. The CPU time is the sum of the user and sys values - both of which are the same for the examples you gave.
You'll find that most of the time in your example is taken up with the initialisation of python itself - so your statistics aren't very useful. I tried this test timing just the evaluations of the two versions of fact and found the reduce version to be consistently about 7 times faster than the recursive version. The reduce version also works for an arbitrarily large n (especially if you change the range to xrange in my earlier posting), and is a rather neat one line.
Re:Why python? (Score:2)
I still disagree with you.
I will grant that the two-liner I wrote was not the most obviously Pythonish in style, though. Just please keep in mind where I come from, functionally speaking.
Python doesn't optimise the tail recursion away
Feh. It should. Tail recursion is elegant.
Re:Why python? (Score:2)
it's procedural! I think that's enough evidence
Re:Why python? (Score:1)
Re:Why python? (Score:2)
If you use range then it allocates a list and populates it with the entire range of numbers requested. If you use xrange then it returns an object that implements the sequence protocol and looks like a list containing the appropriate range of numbers.
So:
for x in xrange( 1000000 ):
print x
is like a standard for loop counting through a million iterations. Whereas the range equivalent would have created a million element list and then iterated over that.
Re:Why python? (Score:2, Informative)
I've have found it an excellent relief from the mundane of C/C++ while re-inforcing the natural idioms of generic programming. I'm Looking forward to working with the Boost Python Library [boost.org]
A survey contrast of Python and C++ [python.org] http://mail.python.org/pipermail/python-list/2002- April/096602.html
Cross platform, Batteries included, good natured community, and script -> OO Ready got me interested, "like I think" factors got me hooked.
(I'm a C++/C applications developer.)
The Weekly Guide to Python Resources [ddj.com]
Re:Why python? (Score:1)
Python Links (Score:3, Informative)
Links in the Top Documentation section of the home page (reproduced here):