Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why is Python a good first scripting language?

20 views
Skip to first unread message

Tim Teebken

unread,
Oct 19, 2002, 4:17:34 PM10/19/02
to
Hello, I'm a Windows developer looking for a versatile, open source
scripting language that runs on Windows and other platforms. I'm not
terribly interested in religious debates about languages, and wouldn't mind
learning several of the open source options eventually. But now I need to
choose one to start with. Here are some things I'm looking for:

(1) Clean, terse, easy-to-read syntax. All subjective terms, and everyone
will claim these apply to their favorite language, but still it's a
distinction worth making. A language that is easier to maintain, and in
which one can quickly become productive, is more helpful to me right now.

(2) Not captive to one methodology. To the man with a hammer, everything
looks like a nail. Though I generally practice and advocate OOP
methodology, I don't want a language so captive to that or any other
approach that it creates extra work in some cases, or makes it impossible to
tackle problems in different ways.

(3) Now to qualify (2): it should not be a language with so many ways of
doing things that you can't identify a "best way," or at least a "good way."
Perl has been noted for having nearly infinite options for tackling
problems, which is a strength and a weakness.

(4) "Fast enough" performance. It doesn't have to be faster than competing
scripting languages, but shouldn't be radically slower.

(5) Extended and extensible. There should be a reasonably large set of free
and commercial modules and extensions available, and it should be possible
to extend it yourself via a lower-level language.

(6) Large user base, active developer community, and a large set of free and
commerical documentation. In other words, it has a healthy "growth index"
and bright future relative to near competitors.

(7) Internal consistency and expressiveness. As with (1), these are
incredibly fuzzy terms, but the point is to find a language that has not
just grown by mindless accretion, like many hospital building plans, where
more "stuff" just gets tacked on in kneejerk reaction over the years. I
value languages where there is some evidence the designer(s) value things
like clarity, consistent semantics, even aesthetic appeal. A "beautiful"
language should get out of your way, should allow you to think about
problems in the world in a way that is simple and elegant, not clumsy, not
overly complicated.


Now with these criteria in mind, I'm considering Python. Already I ruled
out Perl as a first choice, not that it couldn't be useful or even
preferable for certain text processing tasks, but based on some of the
criteria above, and my own viewing of a number of Perl modules, it already
grates on me. Also interesting are some of the functional languages, for
example Haskell, but I wanted something a bit more mainstream for now. A
colleague recommended Ruby, and it does look interesting, although obviously
it doesn't have the size and extend of the Python community yet.

So what it comes down to is, what is it about Python that would make it the
best place to start, when you only have time to learn one scripting
language? Using the criteria above, what makes Python preferable to its
nearest competitors?

Thanks,

--Tim


dsavitsk

unread,
Oct 19, 2002, 5:19:51 PM10/19/02
to
There are *tons* of these threads, but here are my quick answers ...

"Tim Teebken" <tee...@yahoo.com> wrote in message
news:y5js9.10512$Pk1....@nwrddc02.gnilink.net...


> Hello, I'm a Windows developer looking for a versatile, open source
> scripting language that runs on Windows and other platforms. I'm not
> terribly interested in religious debates about languages, and wouldn't
mind
> learning several of the open source options eventually. But now I need to
> choose one to start with. Here are some things I'm looking for:
>
> (1) Clean, terse, easy-to-read syntax. All subjective terms, and
everyone
> will claim these apply to their favorite language, but still it's a
> distinction worth making. A language that is easier to maintain, and in
> which one can quickly become productive, is more helpful to me right now.

This is what Python is all about.

> (2) Not captive to one methodology. To the man with a hammer, everything
> looks like a nail. Though I generally practice and advocate OOP
> methodology, I don't want a language so captive to that or any other
> approach that it creates extra work in some cases, or makes it impossible
to
> tackle problems in different ways.

Python can be used more or less as pure oop, you can write functionally, or
you can write what will look like newbie written vb. it all works.

> (3) Now to qualify (2): it should not be a language with so many ways of
> doing things that you can't identify a "best way," or at least a "good
way."
> Perl has been noted for having nearly infinite options for tackling
> problems, which is a strength and a weakness.

Again, see point 1.

> (4) "Fast enough" performance. It doesn't have to be faster than
competing
> scripting languages, but shouldn't be radically slower.

I've never had a problem.

> (5) Extended and extensible. There should be a reasonably large set of
free
> and commercial modules and extensions available, and it should be possible
> to extend it yourself via a lower-level language.

Python can be extended easily via swig, and it supports COM on win32. Also,
everyone seems to want to post their newest code, so there are many (mostly
good) samples and examples floating around.

> (6) Large user base, active developer community, and a large set of free
and
> commerical documentation. In other words, it has a healthy "growth index"
> and bright future relative to near competitors.

People here are nice, and there seem to be more and more names everyday.

> (7) Internal consistency and expressiveness. As with (1), these are
> incredibly fuzzy terms, but the point is to find a language that has not
> just grown by mindless accretion, like many hospital building plans, where
> more "stuff" just gets tacked on in kneejerk reaction over the years. I
> value languages where there is some evidence the designer(s) value things
> like clarity, consistent semantics, even aesthetic appeal. A "beautiful"
> language should get out of your way, should allow you to think about
> problems in the world in a way that is simple and elegant, not clumsy, not
> overly complicated.

See point 1 one more time.

> Now with these criteria in mind, I'm considering Python. Already I ruled
> out Perl as a first choice, not that it couldn't be useful or even
> preferable for certain text processing tasks, but based on some of the
> criteria above, and my own viewing of a number of Perl modules, it already
> grates on me. Also interesting are some of the functional languages, for
> example Haskell, but I wanted something a bit more mainstream for now. A
> colleague recommended Ruby, and it does look interesting, although
obviously
> it doesn't have the size and extend of the Python community yet.

Haskell and Ruby are nice. So is Python.

-d


Fernando Pérez

unread,
Oct 19, 2002, 6:58:39 PM10/19/02
to
Tim Teebken wrote:

> Hello, I'm a Windows developer looking for a versatile, open source
> scripting language that runs on Windows and other platforms. I'm not
> terribly interested in religious debates about languages, and wouldn't mind
> learning several of the open source options eventually. But now I need to
> choose one to start with. Here are some things I'm looking for:
>
> (1) Clean, terse, easy-to-read syntax. All subjective terms, and everyone

[snip]

From personal experience, in this regard python is better than anything I've
seen in ~12 years of programming with a reasonable set of languages.

> (2) Not captive to one methodology. To the man with a hammer, everything

[snip]

Python starts looking like a normal procedural language, has immediate and
very clean OO access, has functional constructs (even though it's not quite
lisp), and things like list comprehensions from Haskell. Overall I find it
eclectic enough never to feel like a strait jacket.

> (3) Now to qualify (2): it should not be a language with so many ways of
> doing things that you can't identify a "best way," or at least a "good way."
> Perl has been noted for having nearly infinite options for tackling
> problems, which is a strength and a weakness.

Indeed. Having ditched Perl for python about a year ago, I'd say that in this
particular point python shines over perl. While not being overly
constrictive, there tends to be a 'reasonably obvious and best' way of doing
most things. Basically the 'right solution feels natural', which is hardly
the case in Perl (see the man page/cookbook entry for a switch statement in
Perl if you want a good laugh on this topic).


> (4) "Fast enough" performance. It doesn't have to be faster than competing
> scripting languages, but shouldn't be radically slower.

Python is fine here in most cases.

>
> (5) Extended and extensible. There should be a reasonably large set of free
> and commercial modules and extensions available, and it should be possible
> to extend it yourself via a lower-level language.

SWIG, Boost.Python, scipy.weave, Pyrex, Psyco. Pick your choice (each targets
a specific way of speeding things up). This is one of python's greatest
strengths. Think of it this way: if it's good enough for large-scale,
supercomputer-bound scientific codes (with a suitable mix of fortran/C
libraries for the core), it's probably extensible enough for you.

> (6) Large user base, active developer community, and a large set of free and
> commerical documentation. In other words, it has a healthy "growth index"
> and bright future relative to near competitors.

The c.l.py community is great.

> (7) Internal consistency and expressiveness. As with (1), these are

Works great for me. Guido is a mathematician by training, and I think that
shows in python. A certain cleanliness in the design is readily apparent.
Mind you, the language _does_ have warts, but overall I find it very clean
and pleasant to work with.

Ultimately it's a matter of personal preference, but I'd suggest you do give
python a try. Your shopping list sounds almost like a python advocacy piece,
so I'd be willing to bet you'll like it in the long run.

Cheers,

f.

Tim Peters

unread,
Oct 19, 2002, 7:24:02 PM10/19/02
to
[Tim Teebken]
> ...

> So what it comes down to is, what is it about Python that would
> make it the best place to start, when you only have time to learn one
> scripting language? Using the criteria above, what makes Python
> preferable to its nearest competitors?

Well, the criteria above themselves. Grab an interpreter (it's free), fire
up an interactive Python shell, and start playing with the tutorial of your
choice (also free). That's the fastest way to get answers to your questions
you'll believe. You'll like the answer you discover -- unless you're an
idiot <wink>.

that's-always-a-potential-problem-with-tims-ly y'rs - tim


Tim Teebken

unread,
Oct 19, 2002, 8:47:27 PM10/19/02
to
Thank you all for the responses. I'm leaning toward Python, still open to
Ruby. As Tim P. suggested in this thread, now the thing to do is fire up
Python and see how it handles some common tasks. Certainly I've read and
heard enough to think Python is a good choice based on the given criteria.


Courageous

unread,
Oct 19, 2002, 11:32:39 PM10/19/02
to

>> (1) Clean, terse, easy-to-read syntax. All subjective terms, and everyone
>[snip]
>
>From personal experience, in this regard python is better than anything I've
>seen in ~12 years of programming with a reasonable set of languages.

Personally, I agree. I'll make one aside. Some folks, mostly ones already
experienced, are alienated by the lack of specific block delimiters (i.e., braces).
This is, in my opinion, an issue of familiarity.


problems, which is a strength and a weakness.
>
>Indeed. Having ditched Perl for python about a year ago, I'd say that in this
>particular point python shines over perl.

This is at the heart of the historical appeal of python.

C//

Dennis Lee Bieber

unread,
Oct 20, 2002, 12:56:31 AM10/20/02
to
Tim Teebken fed this fish to the penguins on Saturday 19 October 2002
01:17 pm:

> So what it comes down to is, what is it about Python that would make
> it the best place to start, when you only have time to learn one
> scripting
> language? Using the criteria above, what makes Python preferable to
> its nearest competitors?
>

Well, from what I've seen in the one book on Ruby I have... Ruby fails
for the same reason I despise Perl... Python doesn't have the @$#%#$@#!
markers for data items...

I don't care how many times someone shows me how "hello world" is easy
in Perl I just can't get it... APL made more sense to me, even if it
uses greek characters (or ASCII "words" for same): 4 5 $rho 20 ? 52
is something that can be understood (for the pure: 20 random numbers
with no duplicates from a range of 1-52, convert to a 4x5 matrix ...
IE, a numeric representation of four poker hands <G>)


--
--
> ============================================================== <
> wlf...@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulf...@dm.net | Bestiaria Support Staff <
> ============================================================== <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <

Guyon Morée

unread,
Oct 20, 2002, 6:11:33 PM10/20/02
to
...and the number of reactions you got on your question here should have be
a big vote on it's own, too : D


"Tim Teebken" <tee...@yahoo.com> wrote in message

news:z2ns9.11355$Pk1....@nwrddc02.gnilink.net...

Delaney, Timothy

unread,
Oct 20, 2002, 10:13:15 PM10/20/02
to
> From: Guyon Morée [mailto:gu...@amoebe.looze.net]

>
> ...and the number of reactions you got on your question here
> should have be
> a big vote on it's own, too : D

Although I think that the number of responses was reduced since the intial
post sounded like an advocacy piece for Python ;)

Tim Delaney

Alessandro Bottoni

unread,
Oct 20, 2002, 6:10:34 PM10/20/02
to
Alle 22:17, sabato 19 ottobre 2002, Tim Teebken ha scritto:
> Hello, I'm a Windows developer looking for a versatile, open source
> scripting language that runs on Windows and other platforms. I'm not
> terribly interested in religious debates about languages, and wouldn't mind
> learning several of the open source options eventually. But now I need to
> choose one to start with. Here are some things I'm looking for:
>
> (1) Clean, terse, easy-to-read syntax. All subjective terms, and everyone
> will claim these apply to their favorite language, but still it's a
> distinction worth making. A language that is easier to maintain, and in
> which one can quickly become productive, is more helpful to me right now.

Python is considered clean, terse and easy-to-read even by its own enemies...
I personally tried (and sometime I still use) Perl, PHP, Ruby and REXX. No
other language can compare with Python from this point of view.

>
> (2) Not captive to one methodology. To the man with a hammer, everything
> looks like a nail. Though I generally practice and advocate OOP
> methodology, I don't want a language so captive to that or any other
> approach that it creates extra work in some cases, or makes it impossible
> to tackle problems in different ways.

Python allow you to program in any decent way (OOP or Procedural). It DOES
try to keep you from messing up with the code.

>
> (3) Now to qualify (2): it should not be a language with so many ways of
> doing things that you can't identify a "best way," or at least a "good
> way." Perl has been noted for having nearly infinite options for tackling
> problems, which is a strength and a weakness.

If you know Perl and like it, stay away from Python. In Python there IS a
right way to perform a task, even if the language does not force you to use
it.

>
> (4) "Fast enough" performance. It doesn't have to be faster than competing
> scripting languages, but shouldn't be radically slower.

Python is the fastest interpreted language I have ever seen.

>
> (5) Extended and extensible. There should be a reasonably large set of
> free and commercial modules and extensions available, and it should be
> possible to extend it yourself via a lower-level language.

Have a look at the huge amount of modules available at these three sources:
- the STANDARD Python library (supplied with the interpreter)
- the ASPN.activestate.com "cookbook" site
- the "Vaults of Parnassus" web site
Is not it enough?

Extending Python is extremely easy, even if you want to use a C module. Have
a look at SIP or SWIG.

>
> (6) Large user base, active developer community, and a large set of free
> and commerical documentation. In other words, it has a healthy "growth
> index" and bright future relative to near competitors.

Half a megabyte of e-mail messages per day on the python-list is a good index
of the vitality of this language and its community, I think.

>
> (7) Internal consistency and expressiveness. As with (1), these are
> incredibly fuzzy terms, but the point is to find a language that has not
> just grown by mindless accretion, like many hospital building plans, where
> more "stuff" just gets tacked on in kneejerk reaction over the years. I
> value languages where there is some evidence the designer(s) value things
> like clarity, consistent semantics, even aesthetic appeal. A "beautiful"
> language should get out of your way, should allow you to think about
> problems in the world in a way that is simple and elegant, not clumsy, not
> overly complicated.

Python was designed in this way by a very strict group of very brilliant
minds (Guid Von Rossum & C.). The result is a language much more "beautiful"
than every other one (in particular, much better than Perl).

>
>
> Now with these criteria in mind, I'm considering Python. Already I ruled
> out Perl as a first choice, not that it couldn't be useful or even
> preferable for certain text processing tasks, but based on some of the
> criteria above, and my own viewing of a number of Perl modules, it already
> grates on me. Also interesting are some of the functional languages, for
> example Haskell, but I wanted something a bit more mainstream for now. A
> colleague recommended Ruby, and it does look interesting, although
> obviously it doesn't have the size and extend of the Python community yet.

I tried Ruby (and I still use, sometime). It cannot be compared to Python.
Ruby has a very "quirck" sintax and a few weird things I just cannot
appreciate. The community of Ruby is much less "sparkling" than the one of
Python, IMHO.

>
> So what it comes down to is, what is it about Python that would make it the
> best place to start, when you only have time to learn one scripting
> language? Using the criteria above, what makes Python preferable to its
> nearest competitors?
>

The fact that you have just enough time to learn ONE language. Python is the
best investment for your professional future that you could even make.

---------------------
Alessandro Bottoni


Paul-Michael Agapow

unread,
Oct 21, 2002, 6:43:52 AM10/21/02
to

Tim Teebken <tee...@yahoo.com> wrote:
> (1) Clean, terse, easy-to-read syntax. All subjective terms, and everyone
> will claim these apply to their favorite language, but still it's a
> distinction worth making. A language that is easier to maintain, and in
> which one can quickly become productive, is more helpful to me right now.

Python encourages a clean layout of code and good documentation. Also,
I've had a lot of success teaching it to non-programmers (i.e
biologists) for use in data manipulation and simulation. People pick it
up fast and it's not daunting to newcomers.

> (4) "Fast enough" performance. It doesn't have to be faster than competing
> scripting languages, but shouldn't be radically slower.

Python is probably OK here. We wrote a few prototypes that took several
days to run, but the time hit was acceptable for us because we got the
programs written in a week or so. It took the full Java implementation a
year to catch up.

> (6) Large user base, active developer community, and a large set of free and
> commerical documentation. In other words, it has a healthy "growth index"
> and bright future relative to near competitors.

Arguably, this was a weak point of Python in the past. The user
community was small, there were few books and there was the danger (in
the beholder's eye) of the langauge fading. This is not the case any
longer.

> (7) Internal consistency and expressiveness. As with (1), these are
> incredibly fuzzy terms, but the point is to find a language that has not
> just grown by mindless accretion, like many hospital building plans, where
> more "stuff" just gets tacked on in kneejerk reaction over the years.

But enough of Perl, let's talk about Python ... :^)

There are some minor warts in Python IMHO. Of course this all depends on
what you try to do with a langauge, so I can only say that it's never
bothered me.

> grates on me. Also interesting are some of the functional languages, for
> example Haskell, but I wanted something a bit more mainstream for now. A
> colleague recommended Ruby, and it does look interesting, although obviously
> it doesn't have the size and extend of the Python community yet.

Haskell is a bit obscure, I agree, and alien to the most common mode of
programming. Ruby is cool and solid, but the developer community is
still small. It's at the point where Python was 3 or 4 years ago.


--
Paul-Michael Agapow (ne...@agapow.net)

Frithiof Andreas Jensen

unread,
Oct 21, 2002, 7:03:48 AM10/21/02
to

"Tim Teebken" <tee...@yahoo.com> wrote in message
news:y5js9.10512$Pk1....@nwrddc02.gnilink.net...

> Hello, I'm a Windows developer looking for a versatile, open source
> scripting language that runs on Windows and other platforms.

<deleted advocacy for Python ;-)>

Get the Windows distribution off http://www.python.org and run it up!

The *install procedure* should convince you, given that all your other
requirements are easily met:

The installer behaves in the expected way, i.e. there is nothing to scare
even a windows-only user. On top of that the installer is nice about not
littering the systems directories with crap and intelligent enough to notice
if the user does not have "system" priviledges on f.ex. Win 2000 and work
around that!

The uninstall works too!


Roy Smith

unread,
Oct 21, 2002, 9:41:38 AM10/21/02
to
ne...@agapow.net (Paul-Michael Agapow) wrote:
> Ruby is cool and solid, but the developer community is still
> small. It's at the point where Python was 3 or 4 years ago.

I find it fascinating that people who know neither Python nor Ruby seem
th think Ruby is the cooler language.

We've got one hot-shot C++/Java guy here who refuses to even try Python
because he can't get his head past the indentation issue and because
Python's flavor of OO doesn't match his conception of what OO should be.
But, he keeps saying things like, "If I were to learn a scripting
language, I'd learn Ruby".

At the other end of the spectrum, we had another guy here who only
qualified to be called a programmer because he rode the dot-com craze
where anybody who could get a 20-line Perl script to run was called a
programmer. He also knew neither Ruby or Python, but insisted that Ruby
was the way to go, even if his analysis was no deeper technically than
"Python blows, Ruby rules".

If Perl is to Python as Windows is to Macintosh, then I guess Python is
to Ruby as Macintosh is to BeOS :-)

Brett g Porter

unread,
Oct 21, 2002, 10:08:29 AM10/21/02
to

"Roy Smith" <r...@panix.com> wrote in message
news:roy-F65D80.0...@reader1.panix.com...

> ne...@agapow.net (Paul-Michael Agapow) wrote:
> > Ruby is cool and solid, but the developer community is still
> > small. It's at the point where Python was 3 or 4 years ago.
>
> I find it fascinating that people who know neither Python nor Ruby seem
> th think Ruby is the cooler language.
You know, it's funny -- when the pickaxe book came out, I bought it and
loved it. I wasn't surprised, because I loved Hunt & Thomas' book "The
Pragmatic Programmer." After actually playing/working with the language for
a while, Ruby just didn't click for me at all, though. In Python, everything
[+/- epsilon] works more or less as it 'should' -- I can let go of one
trapeze and be confident that Guido's thrown another for me to catch, and
it'll be right where I need it to be.

But every few months I flip through "Programming Ruby" and get seduced by
the writing in that book again, for a few minutes. I intend no slights
against any of the excellent Python authors, but none of the existing Python
books have hit me that way -- I'm hoping that Alex's Nutshell book does (and
history here in c.l.py makes me think that it will).

--
// Today's Oblique Strategy (© Brian Eno/Peter Schmidt):
// Ask your body
// Brett g Porter * BgPo...@acm.org

Michael Stenner

unread,
Oct 21, 2002, 10:06:20 AM10/21/02
to
On Mon, Oct 21, 2002 at 09:41:38AM -0400, Roy Smith wrote:
> ne...@agapow.net (Paul-Michael Agapow) wrote:
> > Ruby is cool and solid, but the developer community is still
> > small. It's at the point where Python was 3 or 4 years ago.
>
> I find it fascinating that people who know neither Python nor Ruby seem
> th think Ruby is the cooler language.

< examples snipped >

I came to python from a strong perl background. And heard a lot of
comparisons of the languages from people of all backgrounds before I
ever tried python. I even defended perl in the whole "python is
prettier" debate. (I never did have a problem with the indentation
thing, though).

Then I finally started playing with python, and have never looked
back. Well, I have looked back enough to port some of my old tools to
python :)

Anyway, the biggest lesson that I have learned is that I now
COMPLETELY ignore comparisons of two languages unless they come from
people who have used BOTH languages EXTENSIVELY. I say this primarily
because I was incapable of saying anything useful (although I didn't
realize it at the time) until I knew both.

-Michael
--
Michael Stenner Office Phone: 919-660-2513
Duke University, Dept. of Physics mste...@phy.duke.edu
Box 90305, Durham N.C. 27708-0305

Donn Cave

unread,
Oct 21, 2002, 1:07:04 PM10/21/02
to
Quoth Roy Smith <r...@panix.com>:

| ne...@agapow.net (Paul-Michael Agapow) wrote:
|> Ruby is cool and solid, but the developer community is still
|> small. It's at the point where Python was 3 or 4 years ago.
|
| I find it fascinating that people who know neither Python nor Ruby seem
| th think Ruby is the cooler language.
...

| If Perl is to Python as Windows is to Macintosh, then I guess Python is
| to Ruby as Macintosh is to BeOS :-)

Which seems to illustrate a corollary: people who only know Python
are sure it's cooler than some other language they don't know. I'm
typing this on a Macintosh running BeOS (Macintosh is a kind of computer,
MacOS and BeOS are operating systems), so to me it seems like you're
trying to make a case for Ruby.

It's actually an interesting way to look at the question. My computer
here is a Power Macintosh 7500, original 1gb disk, memory upgraded to
64Mb and CPU upgraded to 132Mhz PPC604. The way I see it, my options
are a) run BeOS on it, or b) throw it away and ask for a new computer.
Macintosh hardware has gotten a lot bigger and faster since '96 or
whenever it was, and Apple's software has followed along. BeOS 5 is
pretty fast on this hardware, even with only 1/3 Gb disk and therefore
no swap space. MacOS 8.1 is not lightning fast, but bearable if you
don't use a terminal emulator as much as I do. MacOS X struggles on
twice the hardware.

Does your parallel work here? I don't know a thing about Ruby, is it
fast and lean? I know lots of very hard and talented work has been done
to improve Python's performance, but I'm sure it is not the fastest
interpreted language (look at interpreted OCaml for example - not counting
the compiled version, though of course that's how you'd probably use it.)

How about the programming API? Whatever the reasons (you might excuse
Apple because the APIs are a lot older, but Amiga programmers would object),
it's a lot simpler to write a simple BeOS application. Memory management
is simpler and more conventional. The whole API is documented in a single
thick book. Is that Ruby? A simple natural API, compared to Python's
burgeoning repertoire of list incomprehensions, generators and general
obfuscators? Hm, I'm hearing a lot of good things about this Ruby.

Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu

Cameron Laird

unread,
Oct 21, 2002, 2:13:39 PM10/21/02
to
In article <mailman.1035069924...@python.org>,

It might be hard to see the Python content in Tim's advice.
Here it is: the grab-fire up-play process is remarkably
quick and rewarding when Python is the subject. While one
can imagine, say, Java advocates urging the same, their
installations *never* go as cleanly, non-computer people
don't feel comfortable with their language in the first
hour, and so on.
--

Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html

Cameron Laird

unread,
Oct 21, 2002, 2:18:06 PM10/21/02
to
In article <mailman.103518267...@python.org>,
Alessandro Bottoni <alessandr...@infinito.it> wrote:
.
[much valuable
and correct ad-
vice]
.

.
>> (4) "Fast enough" performance. It doesn't have to be faster than competing
>> scripting languages, but shouldn't be radically slower.
>
>Python is the fastest interpreted language I have ever seen.
.
.
.
Not in my experience. 'Fact, I think I can fairly
readily make an objective argument to the contrary,
by comparing Python with OCaML, Perl, ... on
a range of benchmarks.

Python's plenty fast though. It needn't apologize.
While there's plenty of complexity to "fastest", I
simply don't regard Python as in the running.

It remains the single best choice for petitioners
such as Mr. Teebken.

Erik Max Francis

unread,
Oct 21, 2002, 4:58:41 PM10/21/02
to
Paul-Michael Agapow wrote:

> There are some minor warts in Python IMHO. Of course this all depends
> on
> what you try to do with a langauge, so I can only say that it's never
> bothered me.

This is really to be expected with _any_ language, even a very well
designed one (which I would definitely say that Python qualifies). Of
the list of things I would ideally like changed in Python, essentially
everything on the list is minor semantic stuff. They're in fact so
minor that, if I were actually given control over Python for real, I
would be unlikely to implement any of them.

As a functioning programmer who has to use a programming language in the
real world, extensive use of one _should_ result in you noting some
things about it that might be different for your needs (of course, for
someone else whose needs are different, they might note other things
they'd change). In the real world, Python does extremely well.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I want a martini that could be declared a disaster area.
\__/ Capt. Benjamin "Hawkeye" Pierce
Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
A new, virtual planet, every day.

Peter Hansen

unread,
Oct 21, 2002, 6:36:32 PM10/21/02
to
Brett g Porter wrote:
> "Roy Smith" <r...@panix.com> wrote in message
> news:roy-F65D80.0...@reader1.panix.com...
>
>>ne...@agapow.net (Paul-Michael Agapow) wrote:
>>
>>>Ruby is cool and solid, but the developer community is still
>>>small. It's at the point where Python was 3 or 4 years ago.
>>
>>I find it fascinating that people who know neither Python nor Ruby seem
>>th think Ruby is the cooler language.
>
> You know, it's funny -- when the pickaxe book came out, I bought it and
> loved it. I wasn't surprised, because I loved Hunt & Thomas' book "The
> Pragmatic Programmer." After actually playing/working with the language for
> a while, Ruby just didn't click for me at all, though. In Python, everything
> [+/- epsilon] works more or less as it 'should' -- I can let go of one
^^^^^^

Wow! "Everything" _plus_ epsilon... that would be impressive. :-)

-content-free-ly yr's,
Peter

ro...@execulink.com

unread,
Oct 23, 2002, 2:05:38 AM10/23/02
to
Tim Peters <tim...@comcast.net> wrote:

>Well, the criteria above themselves. Grab an interpreter (it's free), fire
>up an interactive Python shell, and start playing with the tutorial of your
>choice (also free). That's the fastest way to get answers to your questions
>you'll believe. You'll like the answer you discover -- unless you're an
>idiot <wink>.

I think we have a new slogan...

Python: the best language, unless you're an idiot.

-- robin

ro...@execulink.com

unread,
Oct 23, 2002, 2:08:49 AM10/23/02
to
Michael Stenner <mste...@phy.duke.edu> wrote:

>Anyway, the biggest lesson that I have learned is that I now
>COMPLETELY ignore comparisons of two languages unless they come from
>people who have used BOTH languages EXTENSIVELY. I say this primarily
>because I was incapable of saying anything useful (although I didn't
>realize it at the time) until I knew both.

And I completley ignore language comparisons because I know Python is
best (unless you're an idiot or have to write device drivers).

-- robin (ex-Perl, Fortran, Basic, xBASE, C)

Courageous

unread,
Oct 24, 2002, 12:25:56 AM10/24/02
to

>I think we have a new slogan...
>
>Python: the best language, unless you're an idiot.

Mod +1, Funny

C//

Martin Rand

unread,
Oct 24, 2002, 2:52:15 AM10/24/02
to
On Mon, 21 Oct 2002 00:10:34 +0200, Alessandro Bottoni
<alessandr...@infinito.it> wrote:

>Alle 22:17, sabato 19 ottobre 2002, Tim Teebken ha scritto:
>> Hello, I'm a Windows developer looking for a versatile, open source
>> scripting language that runs on Windows and other platforms. I'm not
>> terribly interested in religious debates about languages, and wouldn't mind
>> learning several of the open source options eventually. But now I need to
>> choose one to start with. Here are some things I'm looking for:
>>
>> (1) Clean, terse, easy-to-read syntax. All subjective terms, and everyone
>> will claim these apply to their favorite language, but still it's a
>> distinction worth making. A language that is easier to maintain, and in
>> which one can quickly become productive, is more helpful to me right now.
>
>Python is considered clean, terse and easy-to-read even by its own enemies...
>I personally tried (and sometime I still use) Perl, PHP, Ruby and REXX. No
>other language can compare with Python from this point of view.
>

OK, I know one shouldn't get involved in language wars... I've
recently had to move out of Python Haven to look at doing something in
PHP. Why do the words "breakfast" and "dog" keep floating into my
consciousness?...

--
Martin Rand
Highfield Software Ltd
m...@highfield-software.co.uk
Phone: +44 (0)23 8025 2445
Fax: +44 (0)23 8025 2445

Alex Martelli

unread,
Oct 25, 2002, 4:59:30 PM10/25/02
to
Donn Cave wrote:
...

> obfuscators? Hm, I'm hearing a lot of good things about this Ruby.

I think the good things you're hearing are mostly warranted. Ruby and
Python occupy very similar "ecological niches" and share MOST strengths.

One of my dreams is to get together with a Ruby guru one day and write
a balanced comparison of Ruby and Python that will be really helpful to
people who want to choose a really good language for their application
programming and general scripting needs. I think Ruby and Python are
quite close to each other, and heads and shoulders above the other
languages I know.

However (and it may be due to my biases, perhaps, or to my not knowing
enough about Ruby) each time I try to sit down for a balanced, thorough
comparison, I see Python coming out on top -- not by much, perhaps, but
by enough to make it hard for me to be motivated to dig down ever
deeper. For example, you mention speed. Well, consider the sieve.rb
demo script that comes with Ruby (at least in the installation I have
on my Mandrake Linux box), and a Python equivalent:


[alex@lancelot sample]$ time ruby sieve.rb 300000 >/dev/null
6.31user 0.03system 0:06.49elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (248major+921minor)pagefaults 0swaps
[alex@lancelot sample]$ time ruby sieve.rb 300000 >/dev/null
6.29user 0.05system 0:06.48elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (248major+921minor)pagefaults 0swaps

[alex@lancelot sample]$ time python2.2 -O /tmp/sieve.py 300000 >/dev/null
0.77user 0.04system 0:00.85elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (334major+3311minor)pagefaults 0swaps
[alex@lancelot sample]$ time python2.2 -O /tmp/sieve.py 300000 >/dev/null
0.79user 0.02system 0:00.83elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (334major+3311minor)pagefaults 0swaps

[alex@lancelot sample]$ time python2.3 -O /tmp/sieve.py 300000 >/dev/null
0.68user 0.06system 0:00.77elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (343major+4534minor)pagefaults 0swaps
[alex@lancelot sample]$ time python2.3 -O /tmp/sieve.py 300000 >/dev/null
0.72user 0.03system 0:00.77elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (343major+4534minor)pagefaults 0swaps
[alex@lancelot sample]$

Now I'm generally no "speed freak" except for most programming, and
of course I know sieve is hardly a speedy approach to start with, but
it IS a traditional cross-language benchmark, and elapsed time ratios
of 7.7 to 8.4 are starting to give me pause -- particularly when I
see performance getting measurably better in Python 2.3 wrt 2.2 (the
same thing may be happening with Ruby, I don't know -- it IS hard to
get motivated to stay abreast with all of their developments).

Comparing the sources may throw more light (or less...:-):

# sieve of Eratosthenes
max = Integer(ARGV.shift || 100)
sieve = []
for i in 2 .. max
sieve[i] = i
end

for i in 2 .. Math.sqrt(max)
next unless sieve[i]
(i*i).step(max, i) do |j|
sieve[j] = nil
end
end
puts sieve.compact.join ", "


What I see here is a strange (to me) way to fill the sieve array in
the first place (surely there's a fast builtin similar to Python's
range? but if so then why does code coming with Ruby itself and with
the sole purpose of showing Ruby off not use it?) and a peculiar
duality in how you loop -- "for i in" in two cases, a ".step" method
and Ruby's iterator syntax in one other. The Python equivalent:

# sieve of Eratosthenes
import sys, math
max = int((sys.argv+[100])[1])
sieve = range(max+1)

for i in range(2, math.sqrt(max)+1):
if not sieve[i]: continue
for j in range(i*i, max+1, i):
sieve[j] = None

print ', '.join(map(str,filter(None, sieve[2:])))

may definitely not be as "cool", for some definition of the word
"cool":
-- you have to import the modules you want to use, while Ruby has
more builtins -- both ARGV and Math appear automagically in
Ruby's case;
-- Ruby has TWO special syntax forms to indicate ranges (though it
only shows off one here): a..b for a bounds-included range,
a...b for an upper-bound-excluded one -- so Python ends up with
a lot of "+1" as well as a lot of calls to range
-- Python keeps numbers and strings separate, so it needs to
explicitly map str on the range of numbers to make strings
to join
-- python uses functions for many things Ruby wraps as special
syntax forms (such as ..) or object methods (such as .compact
on the sieve object, and even more relevantly .step on the
(i*i) object.

Python can only reciprocate with the "no visible support"
indentation-only structuring, versus Ruby's plethora of "end"
keywords -- while as we know quite a few people detest the
former (particularly if they haven't tried it), I think it
can claim to be "more cool" (novel, distinctive, "exciting").


All in all if "being cool" means impressing your friends with
impressive constructs such as:
(i*i).step(max, i) do |j|
in lieu of Python's mundane "for" and "range", I can see why
Ruby could be considered "cooler". However, for me the main
consideration in choosing a language is simplicity -- simplicity
and regularity... hmmm, the TWO main considerations... anyway,
you get my drift. It seems simpler and more regular to me to
use the "for x in <y>:" form for all iteration-loops, and get more
power out of them by allowing <y> to express more possibilities
(as in Python's relatively-new iterators and generators), rather
than having both the "for" AND iterator-methods on objects. Not
a very deep issue, probably, and I'm sure that, should the need
arise, I could get quite productive with Ruby, too. But that's
the reason I'd eventually like to do a friendly "head-to-head"
article -- to help me understand what, in Ruby's "cool" features,
could possibly make me MORE productive than Python's simplicity.


Alex

Martin v. Loewis

unread,
Oct 25, 2002, 6:38:28 PM10/25/02
to al...@aleax.it
Alex Martelli <al...@aleax.it> writes:

> What I see here is a strange (to me) way to fill the sieve array in
> the first place (surely there's a fast builtin similar to Python's
> range? but if so then why does code coming with Ruby itself and with
> the sole purpose of showing Ruby off not use it?)

I don't know how

for i in 2 .. max

parses, but intuitively, I'd assume that 2 .. max is an expression
that evaluates to something you can draw numbers from, in sequence.

Now, when you say that there is no range() equivalent, I can only
infer that it is something like xrange instead.

Indeed, after some reading, I find

irb(main):012:0> (2 .. 10).type
Range

So ranges are immutable. However, that gives an obvious alternative to
the for loop:

sieve = (2..max).map {|i| i}

I don't know which one is faster, but I doubt Ruby has something like
range. I bet that Python would not have range, either, if xrange was
there first. It is quite special-purpose (why would anybody ever want
to get a hold of the list in a mutable way?), and people would be
pointed to .tolist.

With interactive mode, it is at the border of being intuitive: I found
.methods by pure guessing. This gives me

irb(main):017:0> (1..10).methods
["size", "end", "length", "exclude_end?", "hash", "each", "inspect",
"begin", "==", "last", "eql?", "===", "to_s", "first", "include?",
"grep", "map", "to_a", "find_all", "member?", "sort", "collect",
"detect", "max", "entries", "reject", "each_with_index", "find",
"min", "select", "dup", "protected_methods", "frozen?", "respond_to?",
"class", "kind_of?", "__send__", "nil?", "instance_eval",
"public_methods", "untaint", "__id__", "display", "taint", "=~",
"private_methods", "is_a?", "clone", "equal?", "singleton_methods",
"freeze", "type", "instance_of?", "send", "methods", "method",
"tainted?", "instance_variables", "id", "extend"] In that, I see

irb(main):019:0> (1..10).to_a
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

So I would suggest to re-run the benchmark with

sieve = (2..max).to_a

Regards,
Martin

Alex Martelli

unread,
Oct 26, 2002, 4:29:34 AM10/26/02
to
Martin v. Loewis wrote:

> Alex Martelli <al...@aleax.it> writes:
>
>> What I see here is a strange (to me) way to fill the sieve array in
>> the first place (surely there's a fast builtin similar to Python's
>> range? but if so then why does code coming with Ruby itself and with
>> the sole purpose of showing Ruby off not use it?)
>
> I don't know how
>
> for i in 2 .. max
>
> parses, but intuitively, I'd assume that 2 .. max is an expression
> that evaluates to something you can draw numbers from, in sequence.

Apparently yes, with the upper bound included ( ... instead would
give upper bound excluded).


> Now, when you say that there is no range() equivalent, I can only
> infer that it is something like xrange instead.
>
> Indeed, after some reading, I find
>
> irb(main):012:0> (2 .. 10).type
> Range
>
> So ranges are immutable. However, that gives an obvious alternative to
> the for loop:
>
> sieve = (2..max).map {|i| i}

That doesn't work, any more than range(2, max+1) would in Python:

[alex@lancelot ball]$ ruby sieve.rb
2, 3, 4, 5, 7, 9, 13, 15, 19, 21, 25, 31, 33, 39, 43, 45, 49, 55, 61, 63,
69, 73, 75, 81, 85, 91, 99

i.e. it doesn't identify primes any more -- it's important for that
to start with sieve[i] == i for all relevant values of i, not sieve[0]
set to 2, sieve[1] set to 3, and so on. That's easily fixed (just as
in the case of Python's range!) with (0..max) instead, except that
now it emits "0, 1, 2, 3" etc and I don't know how to slice the final
sieve to start from 2.

Anyway, performance-wise that O(N) initial part obviously makes
negligible difference wrt the O(N squared) part of the sieve itself:

[alex@lancelot ball]$ time ruby sieve.rb 300000 >/dev/null
6.25user 0.05system 0:06.47elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (248major+921minor)pagefaults 0swaps

[alex@lancelot ball]$ time ruby sieve1.rb 300000 >/dev/null
6.47user 0.03system 0:06.62elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (248major+882minor)pagefaults 0swaps

[alex@lancelot ball]$ time ruby sieve2.rb 300000 >/dev/null
6.19user 0.03system 0:06.39elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (248major+882minor)pagefaults 0swaps


sieve.rb is the sample Ruby program (explicit loop), sieve1.rb uses
the map method of (0..max), sieve2.rb uses the to_a method ditto. Much
of a muchness, versus Python's:

[alex@lancelot ball]$ time python2.2 -O sieve.py 300000 >/dev/null
0.76user 0.06system 0:01.09elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (334major+3311minor)pagefaults 0swaps

[alex@lancelot ball]$ time python2.3 -O sieve.py 300000 >/dev/null
0.69user 0.03system 0:00.95elapsed 75%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (343major+4534minor)pagefaults 0swaps


> I don't know which one is faster, but I doubt Ruby has something like
> range. I bet that Python would not have range, either, if xrange was
> there first. It is quite special-purpose (why would anybody ever want
> to get a hold of the list in a mutable way?), and people would be
> pointed to .tolist.

That's pretty special-purpose too -- might as well use the general
approach with list(xrange(N)) then. While as an old APL-er I do
find it quite natural to have a "iota" primitive, rationally I have
to agree that today's Python, with iterators, would offer better
(simpler, more general) ways were it not for backwards compatibility
needs.


> So I would suggest to re-run the benchmark with
>
> sieve = (2..max).to_a

This also fails for the same reason pointed out above, but (0..max).to_a
does succeed and is benchmarked above. It does seem to give a small but
repeatable speedup versus the explicit-loop approach used in the sample
that is distributed with Ruby -- 6.14 to 6.19 usermode CPU time on my
machine for the to_a approach, versus 6.24 to 6.26 for the explicit loop
(and 6.44 to 6.47 for the .map approach) for a sieve on 300,000 items.

But still, all of these times still need to be compared with 0.75-0.77
for Python 2.2, 0.69-0.71 for Python 2.3.


Python's pretty easy to enhance by introducing a function, of course:

# sieve of Eratosthenes
import sys, math
max = int((sys.argv+[100])[1])
sieve = range(max+1)

def dosieve(sieve, max):


for i in range(2, math.sqrt(max)+1):
if not sieve[i]: continue
for j in range(i*i, max+1, i):
sieve[j] = None

dosieve(sieve, max)

print ', '.join(map(str,filter(None, sieve[2:])))


Now THIS is 0.59 to 0.62 with Python 2.2 on my box, 0.54 to 0.56
with Python 2.3. I tried performing a similar transformation on
sieve2.rb, but while it works it doesn't seem to show any performance
advantage wrt the sieve2.rb version which keeps everything global.


Alex

Anna

unread,
Oct 26, 2002, 10:11:41 PM10/26/02
to

Better yet, from a newbie POV, (not only did it install and work
*EXTREMELY* easily on my Windoze box at work, including the system
privileges issue on an NT network) I was actually able to follow the
README provided by GvR with the 2.2.2 bugfix and build the .tar on my
linux box at home. I was amazed at how clear and straightforward it was.

The gurus (like Alex Martelli, Tim Peters, et al) can tell you about how
well Python meets your other requirements... but for ease of learning and
use, and for *documentation*, I can confirm that Python is awesome, and
GvR is a god!

Anna

Dan Schmidt

unread,
Oct 28, 2002, 11:03:13 AM10/28/02
to
For some reason Alex's posts did not show up on my news server; I
didn't see them until the Python-URL! weekly post.

For what it's worth, when I run the sieve programs up to a million I
get a performance difference of a factor of 2, not 8. This is on a
Windows machine, Ruby 1.7.2, Python 2.2.2, with slightly different
code:

=== sieve.rb ===
max = Integer(ARGV.shift || 1000000)
sieve = [nil,nil] + (2..max).to_a

2.upto Math.sqrt(max) do |i|
if sieve[i]


(i*i).step(max, i) do |j|
sieve[j] = nil
end
end

end
s = sieve.compact.join ", "

=== sieve.py ===
import sys, math
max = int((sys.argv+[1000000])[1])
sieve = range(max+1)

for i in range(2, math.sqrt(max)+1):
if not sieve[i]: continue
for j in range(i*i, max+1, i):
sieve[j] = None

s = ', '.join(map(str,filter(None, sieve[2:])))

=== output ===
c:/src $ time ruby sieve.rb
4.497 secs
c:/src $ time ruby sieve.rb
4.457 secs
c:/src $ time python sieve.py
2.273 secs
c:/src $ time python sieve.py
2.273 secs

I don't like Ruby because it is "cool" or to "impress my friends"; I
like it because it is flexible and expressive. In particular, the way
blocks and iterators work together is very nice. On the other hand, I
learned Ruby before Python acquired generators, which fulfill some of
the same functions.

Certainly if one's main considerations in choosing a language are
simplicity and regularity, Python comes out ahead.

For what it's worth, I do use Python more than Ruby, despite my
appreciation of Ruby's features, the main reasons being:
- Python does seem to be faster
- Python's non-core libraries are more robust
- Python is likelier to be installed on others' machines
- I prefer indentation-only structuring to all those "end" keywords
- I'm more familiar with Python (finally the simplicity criterion! :)

But I think it is a little unfair to Ruby users to characterize their
reasons for using Ruby with phrases such as "being cool" and
"impressing your friends."

Dan

--
http://www.dfan.org

Michael Hudson

unread,
Oct 30, 2002, 8:26:43 AM10/30/02
to al...@aleax.it
Alex Martelli <al...@aleax.it> writes:

> [alex@lancelot ball]$ time python2.3 -O sieve.py 300000 >/dev/null

^^
This shouldn't make much difference with 2.3...

> 0.69user 0.03system 0:00.95elapsed 75%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (343major+4534minor)pagefaults 0swaps

You have a fast machine!

[...]


> Now THIS is 0.59 to 0.62 with Python 2.2 on my box, 0.54 to 0.56
> with Python 2.3. I tried performing a similar transformation on
> sieve2.rb, but while it works it doesn't seem to show any performance
> advantage wrt the sieve2.rb version which keeps everything global.

This sieve is the second quickest I know in Python (it's due to Tim
Peters):

def sieve(n):
if n < 2:
return []
limit = int(math.sqrt(n))
primes = range(1, n+1, 2)
primes[0] = 0
n = len(primes)
for p in primes:
if not p: continue
if p <= limit:
# note that p*p is odd, so no need to subtract 1
# before shifting right -- same thing in the end
for i in xrange((p*p)>>1, n, p):
primes[i] = 0
continue
break
primes[0] = 2
return filter(None, primes)

It seems to be three-and-a-bit times quicker than yours (and it may be
algorithmically better too, not sure). The *fastest* I know is due to
Christian Tismer, and is completely out of control:

def tissieve6(n):
if n < 2: return []
candidates = range(-1, n+1, 3)
# yes they are wrong, adjusted later.
sq = math.sqrt(n)
end = sys.maxint
candidates[:2] = [0, 0]
for p in candidates:
if p:
if p%2==0: p=p-1
if p>sq : break
dist = p2 = p+p
if p%3 == 1: dist=dist+dist
dist = dist/3
try: # indexing too far
for q in xrange( (p*p+3)/3, end, p2):\
candidates[q] = 0 ;\
candidates[q+dist] = 0
except:pass
candidates[:2] = [2, 3]
candidates = filter(None, candidates)
for i in xrange(1, len(candidates)):
if candidates[i]%2 == 0:\
candidates[i] = candidates[i]-1
return candidates

This is from this thread

http://groups.google.com/groups?threadm=36921CBF.4A5450FB%40appliedbiometrics.com

back in 1999, which is fun reading.

...

Interesting! Tim's version is quicker with python 2.3. I'd dig into
why, if I cared <wink>.

Cheers,
M.

--
MAN: How can I tell that the past isn't a fiction designed to
account for the discrepancy between my immediate physical
sensations and my state of mind?
-- The Hitch-Hikers Guide to the Galaxy, Episode 12

Wojtek Walczak

unread,
Oct 30, 2002, 11:40:47 AM10/30/02
to
Dnia Fri, 25 Oct 2002 20:59:30 GMT, Alex Martelli napisał(a):
> One of my dreams is to get together with a Ruby guru one day and write
> a balanced comparison of Ruby and Python that will be really helpful to
> people who want to choose a really good language for their application
> programming and general scripting needs.
IMHO it'll be very^2 hard since it's rather a personal matter.
Anyone who wants to choose, need to learn both Python and Ruby,
and decide in which one he feels better.
You can write a comparision, but it'll always be far away from
an oracle ;]

--
[ Wojtek gminick Walczak ][ http://gminick.linuxsecurity.pl/ ]
[ gminick (at) hacker.pl ][ gminick (at) underground.org.pl/ ]

Alex Martelli

unread,
Oct 31, 2002, 3:43:24 AM10/31/02
to
Michael Hudson wrote:

> Alex Martelli <al...@aleax.it> writes:
>
>> [alex@lancelot ball]$ time python2.3 -O sieve.py 300000 >/dev/null
> ^^
> This shouldn't make much difference with 2.3...

Right, but I always specify -O when measuring times -- a habit that's
worth keeping at least until every version older than 2.3 gets excised
from one's machine (a time in the future...).


>> 0.69user 0.03system 0:00.95elapsed 75%CPU (0avgtext+0avgdata
>> 0maxresident)k 0inputs+0outputs (343major+4534minor)pagefaults 0swaps
>
> You have a fast machine!

An 18-months-old 1.2 GHz AMD Athlon with 512MB of used-to-be-good-back-then
DDR RAM and Linux Mandrake 8.2. Hardly "state of the art" even when I
configured it (no RAMBUS or anything like that!) and surely way behind
the _current_ state of the art these days.

> This sieve is the second quickest I know in Python (it's due to Tim
> Peters):

Unfortunately I'm not enough of a Ruby coder to be able to transcribe
this (or Tismer's Sieve which you give later) to Ruby...


Alex

Magnus Lyckå

unread,
Oct 31, 2002, 2:06:24 PM10/31/02
to

I tried this, with surprising result... (Python 2.2.1)
The surprise isn't the speed, but that Tismer's version
finds more primes, like 25, 35, and 49... Something missing?

Alex Martelli Version
0.000488050855626
2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67,
71, 73,
79, 83, 89, 97
Tim Peters Version
0.000227682568595
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67,
71, 73,
79, 83, 89, 97]
Christian Tismer Version
0.000374907984115
[2, 3, 5, 7, 11, 13, 17, 19, 23, 25, 29, 31, 35, 37, 41, 43, 47, 49, 53,
55, 59,
61, 65, 67, 71, 73, 77, 79, 83, 85, 89, 91, 95, 97]

Patrick Ellis

unread,
Nov 3, 2002, 12:54:49 AM11/3/02
to
"Michael Hudson" <m...@python.net> wrote:
>
> This sieve is the second quickest I know in Python (it's due to Tim
> Peters):
>
> def sieve(n):
> if n < 2:
> return []
> limit = int(math.sqrt(n))
> primes = range(1, n+1, 2)
> primes[0] = 0
> n = len(primes)
> for p in primes:
> if not p: continue
> if p <= limit:
> # note that p*p is odd, so no need to subtract 1
> # before shifting right -- same thing in the end
> for i in xrange((p*p)>>1, n, p):
> primes[i] = 0
> continue
> break
> primes[0] = 2
> return filter(None, primes)
>
> This is from this thread
>
http://groups.google.com/groups?threadm=36921CBF.4A5450FB%40appliedbiometric
s.com
> back in 1999, which is fun reading.
>
> Interesting! Tim's version is quicker with python 2.3. I'd dig into
> why, if I cared <wink>.

I was playing with this and found that looping on this function resulted in
increasing run time for each iteration (for Python 2.2.1 on Windows ME).

for i in range(10):
start = time.time()
primes = sieve(10000000)
stop = time.time()
primes = None
print "Primes took %7.3f seconds"%((stop-start))

Results in:

Primes took 6.370 seconds
Primes took 7.470 seconds
Primes took 8.080 seconds
Primes took 8.300 seconds
Primes took 8.400 seconds
Primes took 8.460 seconds
Primes took 8.510 seconds
Primes took 8.570 seconds
Primes took 8.570 seconds
Primes took 8.620 seconds

Note that removing the primes = None line results in settling around 8.9
instead of 8.6. My guess is this has to do with allocating and deallocating
millions of integer objects to put in the primes list. The 0.3 sec
difference is how long it takes to deallocate the returned list. Python 2.3
does memory more efficiently and is why it runs faster.

I came up with a new version that uses the Numeric package. It is
algorithmically identical, just with a few implementation changes.

def sieve(n):
if n < 2:
return []

limit = (int(math.sqrt(n)) / 2) + 1
primes = Numeric.arrayrange(1, n+1, 2)
n = len(primes)
for p in primes[1:limit]:
if p:


# note that p*p is odd, so no need to subtract 1
# before shifting right -- same thing in the end

primes[(p*p)>>1::p] = 0
return list(Numeric.nonzero(primes))

The same test as above results in:

Primes took 1.870 seconds
Primes took 1.810 seconds
Primes took 1.760 seconds
Primes took 1.810 seconds
Primes took 1.870 seconds
Primes took 1.750 seconds
Primes took 1.820 seconds
Primes took 1.810 seconds
Primes took 1.810 seconds
Primes took 1.810 seconds

Because it uses arrays that store the integers directly, instead of many
tiny integer objects, it doesn't have the memory management overhead and
resulting increasing runtime. The biggest speed increase is replacing the
inner loop with an assignment statement to a slice (which doesn't work with
lists).

8.57 sec / 1.81 sec = 4.7 times faster.

I was impressed with how easy it was to switch from list to Numeric array.
Just switching from range to arrayrange changes the entire function over,
without any other code changes. It was a good speedup by itself and
eliminated the memory allocation problems.

Patrick Ellis


Michael Hudson

unread,
Nov 5, 2002, 10:14:46 AM11/5/02
to
"Patrick Ellis" <pel...@tampabay.rr.com> writes:

> Note that removing the primes = None line results in settling around 8.9
> instead of 8.6. My guess is this has to do with allocating and deallocating
> millions of integer objects to put in the primes list.

And that WinME's memory management appears to suck harder than vacuum.
I haven't tried this, but I bet you wouldn't see that on almost any
other operating system (except possible classic macos).

> The 0.3 sec difference is how long it takes to deallocate the
> returned list. Python 2.3 does memory more efficiently and is why it
> runs faster.

Also, it does let Win32's malloc get near enough to the action to get
confused.

Impressive!

> Because it uses arrays that store the integers directly, instead of many
> tiny integer objects, it doesn't have the memory management overhead and
> resulting increasing runtime. The biggest speed increase is replacing the
> inner loop with an assignment statement to a slice (which doesn't work with
> lists).

It does in Python 2.3 though, and attempting to exploit that found a
bug in the extended slice support (that I wrote, oops). Anyway, it
was fairly easy to fix, so you've helped Python development with this
post! Bet you didn't expect that.

Helps the speed a bit, but not enormously (20% or so).

Cheers,
M.

--
Just point your web browser at http://www.python.org/search/ and
look for "program", "doesn't", "work", or "my". Whenever you find
someone else whose program didn't work, don't do what they
did. Repeat as needed. -- Tim Peters, on python-help, 16 Jun 1998

0 new messages