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

Python vs. Perl, which is better to learn?

13 views
Skip to first unread message

David

unread,
Apr 30, 2002, 1:11:31 AM4/30/02
to
I have a lot of experience in ANSI C/C++, I want to learn a new
language and which it can help me in the work.
I just want to clear which(python or perl) is more comfort for me?

Chris

unread,
Apr 30, 2002, 1:28:13 AM4/30/02
to
In article <df30afd4.02042...@posting.google.com>,
xiaots...@hotmail.com (David) wrote:

In terms of how it looks, Perl might look more comfortable, but Python
is likely to function more similarly to C++, while C will have more in
common with Perl.

Learn both.

Richard Jones

unread,
Apr 30, 2002, 1:37:48 AM4/30/02
to

Perl will have more familiar things:
. braces for block delimitation
. distinction between pointers and values
. semicolon statement endings

Python, on the other hand, throws these annoying language burdens out the
window (in python, indentation delimits blocks, the parser is smart enough to
know when a statement finishes and all variables are references to values).
It does have a large amount of familarity for the C programmer - some of the
syntax is similar, a large amount of the OS libraries look like their C
equivalents, but with all the housekeeping done for you.

I understand that Python's easier to extend in C (having done some myself, I
know it's really simple) and C++.

Python is also much, much easier to learn than Perl. Nuff said, really.


Richard

Delaney, Timothy

unread,
Apr 30, 2002, 1:43:48 AM4/30/02
to
> From: xiaots...@hotmail.com [mailto:xiaots...@hotmail.com]

>
> I have a lot of experience in ANSI C/C++, I want to learn a new
> language and which it can help me in the work.
> I just want to clear which(python or perl) is more comfort for me?

http://www.python.org/doc/Comparisons.html

Tim Delaney


Andrew McNamara

unread,
Apr 30, 2002, 2:03:17 AM4/30/02
to
>I have a lot of experience in ANSI C/C++, I want to learn a new
>language and which it can help me in the work.
>I just want to clear which(python or perl) is more comfort for me?

I've been using (and abusing) perl for many years, and I'm still not
comfortable using it. Not only that, but because there are so many ways of
expressing things in perl, I often can't understand my own code 6 months
down the track (at least, at first glance). I'd go as far as to say the
sendmail.cf language is simpler, easier to learn and maintain than perl.

Python on the other hand is a lot of fun. Good designs tend to happen
more often and with less effort, and the language doesn't get in the way
(it works the way you expect it to work).

And, in fact, Python has changed (for the better) the way I code C - I
want the dynamicism of Python, so I spend more time coding infrastructure,
which pays off when the inevitable "can you make it do this" comes along.

--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


Garry Taylor

unread,
Apr 30, 2002, 5:05:36 AM4/30/02
to
Chris <ch...@cmb-enterprises.com> wrote in message news:<chris-4E0B1A....@corp.supernews.com>...

I use Perl at work day in day out, and use Python for my own personal
stuff, I would say that Python is better for pretty much everything,
particularly larger programs, where it's more structured syntax makes
code easier to read. I quite like Perl for CGI scripting, and little
1-page scripts, but would never contemplate using it for a big
project.

Learning both is an ideal solution, but personally I wish I started on
Python far earlier than I did.

Garry

JohnO

unread,
Apr 30, 2002, 5:32:47 AM4/30/02
to
Garry Taylor wrote:


I don't know if anyone else has noticed this but I've found that operators
and sys admins use perl and that developers tend towards python. Also sys
admins rarely utilise indirection but developers do.

John

Tom Chance

unread,
Apr 30, 2002, 10:37:35 AM4/30/02
to
I started off by learning Perl a few years ago, and I'm now starting to
learn python. I've found that learning both is extremely valuable, both
because learning python has really strengthened and deepened my
understanding of perl, and because they both perform very different
functions. Perl excels at things like administration scripts and
programs, web pages and anything requiring complex text processing.
Python excels at developing full programs, and prototypes for C/C++
programs. If you can put both under your belt, you'd be a lot better off
for it.

As for which first, well that depends slightly on your priorities, but
if you have none, I'd learn Perl first, because the syntax will be more
familiar to you, and then when you've got past the more advanced topics
like references and writing perl modules, move onto python. O'Reilly's
"Learning Python" would be an excellent introduction for you, as it
constantly compares Python to C/C++.

Tom

Aahz

unread,
Apr 30, 2002, 1:13:01 PM4/30/02
to
In article <mailman.1020147892...@python.org>,

Andrew McNamara <and...@object-craft.com.au> wrote:
>
>I'd go as far as to say the
>sendmail.cf language is simpler, easier to learn and maintain than perl.

.sigfile?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"I used to have a .sig but I found it impossible to please everyone..." --SFJ

Andrei Kulakov

unread,
Apr 30, 2002, 2:07:00 PM4/30/02
to
What do you mean by indirection?


--
Cymbaline: intelligent learning mp3 player - python, linux, console.
get it at: cy.silmarill.org

Max

unread,
Apr 30, 2002, 2:11:24 PM4/30/02
to
----- Original Message -----
From: "JohnO" <j...@johnochiltree.uklinux.net>
Newsgroups: comp.lang.python
Sent: Tuesday, April 30, 2002 11:32 AM
Subject: Re: Python vs. Perl, which is better to learn?


> Garry Taylor wrote:

[...]

> I don't know if anyone else has noticed this but I've found that operators
> and sys admins use perl and that developers tend towards python. Also sys
> admins rarely utilise indirection but developers do.
>
> John

Interesting... i had the same feeling!
I'm pretty new to Python, but it's very close to the way i think... i can
concentrate on the problem and not on how to implement my solution... very
very powerful for an analyst/programmer....


Bob Melson

unread,
Apr 30, 2002, 2:01:24 PM4/30/02
to
In article <aamjat$qku$1...@panix1.panix.com>,

aa...@pythoncraft.com (Aahz) writes:
> In article <mailman.1020147892...@python.org>,
> Andrew McNamara <and...@object-craft.com.au> wrote:
>>
>>I'd go as far as to say the
>>sendmail.cf language is simpler, easier to learn and maintain than perl.
>
> .sigfile?

Look at it this way -- you pick the best language tool to do the job at
hand. If python is the better language for that job, you use python; if
it's perl, then you use perl; if it's some other language, you use _that_
language. If you're asked to build a house, you certainly don't confine
yourself to a single tool -- you use the tools appropriate to the job you
have to do; why should it be different with scripting languages?

Bob Melson

Cameron Laird

unread,
Apr 30, 2002, 3:18:42 PM4/30/02
to
In article <slrnactn...@ak.silmarill.org>,
Andrei Kulakov <a...@silmarill.org> wrote:
.
.
.

>> I don't know if anyone else has noticed this but I've found that operators
>> and sys admins use perl and that developers tend towards python. Also sys
>> admins rarely utilise indirection but developers do.
>>
>What do you mean by indirection?
.
.
.
That one more application of which is alleged to solve all
algorithmic problems (look for "David Wheeler" in <URL:
http://www1.ics.uci.edu/~rohit/IEEE-L7-namespaces.html >).
Examples: in Python we idomatically parametrize by putting
stuff in a dictionary, and computing with the dictionary.
The previous correspondent was saying something like this:
"sysads write
log('/tmp/mylogfile');
where developers are likely to put
logfile = '/tmp/mylogfile'
...
log(logfile)
"

"Indirection" means something different in psychology,
journalism, and so on.
--

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

James J. Besemer

unread,
Apr 30, 2002, 1:29:45 PM4/30/02
to

David wrote:

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

Even without knowing your background I think one can confidently predict
that Python will be lots more "comfortable" for you, at least if you are
at all normal.

Both languages are of comparable power and capability. Perl has been
around longer so it has attracted a wider following, though Python is
gradually catching up.

Python is a carefully designed language with a few consistent rules.
It's a first-class programming language.

Perl is a hodge-podge of random features and syntax thrown together.
It's more like a super-fancy C-Shell scripting language.

I think it's a known fact that the amount of goofy punctuation in Perl
will lower your productivity by 20-30% and shorten your life by several
years. ;o)

I mean really, a variable is one of the most common "objects" in any
programming language. What the frig is with having to prefix every one
with a dollar sign (or some other particle of punctuation)? What the
frig is with NOT being able to define the arguments to your
functions/subroutines?

Perl appeals to gnomes who like programming tricks, secret handshakes
and language puns. Python tends to attract people who value clarity of
expression You will continually be perplexed, surprised, frustrated
and amazed (in a bad way) with Perl. You will be continually pleased,
encouraged, rewarded and amazed (in a good way) with Python.

Of course if you asked a Perl group they'd say you'd be better off with
Perl. But they'd be lying. ;o)

Regards

--jb

--
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:j...@cascade-sys.com


Aahz

unread,
Apr 30, 2002, 5:34:45 PM4/30/02
to
In article <aamm5k$kv3$1...@bubba.NMSU.Edu>,

Bob Melson <"mel...@earthlink.net"> wrote:
>
>Look at it this way -- you pick the best language tool to do the job at
>hand. If python is the better language for that job, you use python; if
>it's perl, then you use perl; if it's some other language, you use _that_
>language. If you're asked to build a house, you certainly don't confine
>yourself to a single tool -- you use the tools appropriate to the job you
>have to do; why should it be different with scripting languages?

Fine sentiment. Now, under what circumstances would you recommend Perl
over Python?

Carl Banks

unread,
Apr 30, 2002, 7:02:53 PM4/30/02
to


So you agree that he shouldn't bother with Perl.


--
CARL BANKS http://www.aerojockey.com
"Nullum mihi placet tamquam provocatio magna. Hoc ex eis non est."

Billy Ng

unread,
Apr 30, 2002, 9:53:09 PM4/30/02
to
I am also new to python. I think python will be my replacement of perl.
However, if I need to do very heavy regular expression, I still prefer perl.
I just don't feel comfortable with the python's re syntax.

Billy Ng

"Max" <pr...@prova.it> wrote in message
news:g7Bz8.35106$8D3.1...@news1.tin.it...

Patrick W

unread,
Apr 30, 2002, 11:05:54 PM4/30/02
to
rme...@gilia.nmsu.edu ("Bob Melson") writes:

> If you're asked to build a house, you certainly don't confine
> yourself to a single tool -- you use the tools appropriate to the
> job you have to do; why should it be different with scripting
> languages?

Because the "right tool for the right job" approach is wrong in this
context. It should apply to the choice of language _categories_, not
languages _within_ a category. There are better things to do with time
and mental energy than learn a dozen different ways of doing the same
thing.

If it took a minimum of six months to learn how to push two different
brands of wheelbarrow, can you imagine an experienced builder saying
to his apprentice: learn both?

Andrew McNamara

unread,
Apr 30, 2002, 10:34:10 PM4/30/02
to
>I am also new to python. I think python will be my replacement of perl.
>However, if I need to do very heavy regular expression, I still prefer perl.
>I just don't feel comfortable with the python's re syntax.

Well, the RE syntax itself should be (almost?) identical - I guess
you're refering to way the re module is used (that it's not part of
Python's syntax)?

I'd suggest you not let this discourage you - while I initially avoided
using RE's in Python, I quickly came to love the rest of the language,
and then found that not having RE's in the language's syntax was not the
problem I thought it was (you rapidly discover better ways of working -
superior, I would argue, to working in perl).

Geoff Gerrietts

unread,
Apr 30, 2002, 10:24:57 PM4/30/02
to
Quoting Billy Ng (kwo...@earthlink.net):
> I am also new to python. I think python will be my replacement of
> perl.
> However, if I need to do very heavy regular expression, I still
> prefer perl.
> I just don't feel comfortable with the python's re syntax.

I understand your discomfort; I had it at first, too. I still
sometimes use Perl for a one-liner (eg perl -pi -e "s/^\s+//g;"), but
I've found that Python's regular expressions are just fine; it's a
matter of getting accustomed to it.

Of particular interest to me (and maybe Perl does this now, but it
didn't when I was deep into Perl Zen) is the way you can name
subpatterns in Python -- that allows you to use your parens for
grouping, and not hafta pick through the countless groups for the
actual pieces you want to extract.

I also appreciate the way Python actively encourages a person to
compile their regular expressions -- Perl doesn't, which leads to
continually re-constructing the state machine (unless they've
optimized that since I was deep into Perl Zen).

Luck,
--G.

--
Geoff Gerrietts "There is no fate that cannot be
<geoff at gerrietts net> surmounted by scorn." --Albert Camus


Mark McEahern

unread,
Apr 30, 2002, 11:05:58 PM4/30/02
to
[Billy Ng]

> I am also new to python. I think python will be my replacement of perl.
> However, if I need to do very heavy regular expression, I still
> prefer perl.
> I just don't feel comfortable with the python's re syntax.

I've heard this sentiment expressed before. I can count on my hands the
number of times I've used Perl--all before I learned about Python--so I'm
largely ignorant of Perl.

Could you give us a concrete example where the use of regular expressions in
Perl is superior to Python?

Thanks,

// mark

Billy Ng

unread,
May 1, 2002, 12:26:21 AM5/1/02
to
Don't get me wrong. I said I did not feel comfortable to use Pytohn RE
because I am not familiar with the methods. I don't mean that the Python
one is not as good as Perl. :-)

Billy Ng

"Mark McEahern" <mark...@mceahern.com> wrote in message
news:mailman.1020222424...@python.org...

Andrew Dalke

unread,
May 1, 2002, 12:48:29 AM5/1/02
to
Geoff Gerrietts :

>Of particular interest to me (and maybe Perl does this now, but it
>didn't when I was deep into Perl Zen) is the way you can name
>subpatterns in Python -- that allows you to use your parens for
>grouping, and not hafta pick through the countless groups for the
>actual pieces you want to extract.

It doesn't handle that. I mentioned that to Damian Conway as one
of the things to consider supporting in Perl6, since I agree --
I use them all the time for my work.

>I also appreciate the way Python actively encourages a person to
>compile their regular expressions -- Perl doesn't, which leads to
>continually re-constructing the state machine (unless they've
>optimized that since I was deep into Perl Zen).

That was supported even when I started with Perl 4.036. It
just doesn't look like it works that way.

http://www.perldoc.com/perl5.6.1/pod/perlretut.html
] Even with all this work, regexp matching happens remarkably fast.
] To speed things up, during compilation stage, perl compiles the
] regexp into a compact sequence of opcodes that can often fit
] inside a processor cache.

Andrew
da...@dalkescientific.com

Christopher Browne

unread,
May 1, 2002, 1:02:07 AM5/1/02
to

Well, in Perl, they're "first class objects," as it were, requiring no
extra references to functions to get them to function, as a base part
of the language syntax.

If you're using regexes really a lot, that could easily be preferable.

Mind you, I have found that the "More Pythonic Way" of constructing
complex regexes by building components, like the following, to have
merit:

digit = '[0-9]'
date = '\(' + digit + digit + digit + digit + '/' + digit + digit + '/'
date = date + digit + digit + '\)'

By building the regex out of something with named components, I don't
have the horridness of line noise like:
if ($line =~ /.*\s+\d+.\d+\s+\d+.\d+\s+.\d+.\d+/) {

Ultimately, the answer is that both approaches have their own merits
and demerits. The "Perl thing" tends to be shorter, while the "Python
thing" tends to be more readable.

What do you want to prefer?
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www3.sympatico.ca/cbbrowne/emacs.html
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond where
the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh

James J. Besemer

unread,
May 1, 2002, 12:56:05 AM5/1/02
to

Mark McEahern wrote:

> Could you give us a concrete example where the use of regular expressions in
> Perl is superior to Python?

Superior probably is too strong a word, though regex in Perl is a little easier
to get to right out of the box. I.e, regex is part of Perl's "builtins".


PERL regex example:

# No import, compile, function or object syntax.
# Implied match is with the "current" thingy ( $_, IIRC)

action() if /regex/ ; # perform action() if regex match

To match with a specific object, say, a variable you use the "=~" operator.

action( $a) if $a =~ /regex/ ; # perform action if regex matches $a

Note that the statement for substitute is like the "vi" command:

$a ~ s/old/new/gi if $a =~ /pattern1/;

# substitue "new" for "old" in $a if $a matches pattern1
# g suffix for global replacement
# i suffix for case insensitive comparison

I personally find some of these forms to be abominations but they are highly
mnenomic to people who have used Unix for a long time.

The basic regex operators are similar to Python's, though Perl adds some extras
such as

{n,m} # preceeding pattern matches at least n but no more than m times

A successful match sets a flurry of global variables:

$& = the matched portion of the input string

$` = everything before the match

$' = everything after the match

Parentheses in the regex break the matching pattern into "groups" and the
portions of the string coresponding to each group may be accessed via:

$1, $2, ...

E.g.,

s/^([^ ]* *([^ ]*)/$2 $1/; # reverse order of 2 words

if( /Time: (..):(..):(..)/ ){ # extract hh:mm:ss fields
$hours = $1;
$min = $2;
$sec = $3;

Ian Bicking

unread,
May 1, 2002, 2:03:35 AM5/1/02
to
On Wed, 2002-05-01 at 00:02, Christopher Browne wrote:
> Mind you, I have found that the "More Pythonic Way" of constructing
> complex regexes by building components, like the following, to have
> merit:
>
> digit = '[0-9]'
> date = '\(' + digit + digit + digit + digit + '/' + digit + digit + '/'
> date = date + digit + digit + '\)'
>
> By building the regex out of something with named components, I don't
> have the horridness of line noise like:
> if ($line =~ /.*\s+\d+.\d+\s+\d+.\d+\s+.\d+.\d+/) {

Sounds like you want SNOBOL-like regexes, perhaps? I feel like someone
implemented something along those lines for Python, probably more as an
experiment than for practical reasons. I've also seen Lispy regex
engines where you really feel like you are creating a state machine
(which you more or less are anyway -- it just feels more like it). I
can't remember them well, but I feel like you express it like
'("(" digit digit digit digit "/" digit digit ...)
probably with other operators, so you wouldn't have to write "digit
digit digit digit" and such.

These of course could also be implemented in Python -- though the Lisp
syntax may actually be an advantage here (or at least the separation of
strings and symbols). Since Python doesn't give any special preference
to Perl-like regexes, it's just as possible to have a re2 library, with
re2.compile([regex expressed as a list...]), where the compiled objects
otherwise act just like re compiled objects, and are thus
interchangeable. Considering how Dark and Mysterious regexes are to
novices, this might be well worth it.

Ian


Andrew Dalke

unread,
May 1, 2002, 2:32:12 AM5/1/02
to
Christopher Browne:
>Well, in Perl, [regular expressions are] "first class objects," as

>it were, requiring no extra references to functions to get them to
>function, as a base part of the language syntax.

He-he. I remember once posting the following

$patterns = '';
sub add_pattern {
my($pat, $name) = @_;
$patterns .= "if (\$str =~ /$pat/) { \$count++;
print 'Found $name\n'; }\n";
}
sub search {
my($str) = $_[0];
my($count) = 0;
eval $patterns;
return $count;
}


because I learned Perl in the 4.036 days and that was the only way
to make a regexp pattern on the fly. Nowadays there's the qr() and
other command (I've completely forgotten them by now). Anyway, after
posting it someone else said:
] the technique of building a regex sub on the fly and eval'ing it is very
] old and was the standard way to test multiple regexes with decent
] efficiency. it is not well know by newbies but most perl hackers had it
] in their idiom toolbox.

which made me feel pretty ancient.

So in my way of viewing, Perl regexps are fundamental data types
but *were* second-class objects, in that it was impossible to have an
array of regular expressions. I think you mean the first of these
and not the second. Now I think Perl regexps are both fundamental
and first class.

I do love that Python's regexp patterns are parsed in Python, which
has let me play around with modified regexp patterns. I also love
that Python's module approach lets it handle at least three different
regular expression libraries in a similar fashion (old-style regexp,
new-style re/src, and posix).

If you really want, there's a 403 article thread from late 1998 titled
Perl & Java - differences and uses
which contains my thoughts on this matters.

>Mind you, I have found that the "More Pythonic Way" of constructing
>complex regexes by building components, like the following, to have
>merit:
>
> digit = '[0-9]'
> date = '\(' + digit + digit + digit + digit + '/' + digit + digit + '/'
> date = date + digit + digit + '\)'

I've tried doing this, but it's almost impossible to find mismatched
parens. Instead, consider something like Greg Ewing's Plex, which
uses functions to build up these terms, and let's Python's parsing
catch some of the problems.

Andrew
da...@dalkescientific.com

Alex Martelli

unread,
May 1, 2002, 2:59:10 AM5/1/02
to
Christopher Browne wrote:
...

>> Could you give us a concrete example where the use of regular expressions
>> in Perl is superior to Python?
>
> Well, in Perl, they're "first class objects," as it were, requiring no
> extra references to functions to get them to function, as a base part
> of the language syntax.

I don't think this is the accepted and commonly used definition of "first
class object". http://www.cs.unm.edu/~crowley/phdExams/1997xfall/pl.html
for example:
"""
A first class object in a programming language is a language object that
can be created dynamically, stored in a variable, passed as a parameter to
a function and returned as a result by a function.
"""

It's true that Perl has several things "bundled" as an intrinsic,
non-negotiable part of "the basic language" which Python places in separate
modules. For example, in Perl, @ARGV is an intrinsic global variable that
holds the script's arguments, while in Python the same arguments are held
in sys.argv and thus to access them you need an 'import sys'. I think it
would be misleading to argue that this makes the arguments "first class" in
Perl and not in Python -- they're just as easy to access and use in either
case, it's just that, in Python, they're not willy-nilly injected into your
top-level namespace when you don't care about them.

The situation is basically identical wrt regular expressions. Ease of use
and power are the same. I've recoded lots of Perl scripts into Python, and
re's were the least of the translation difficulties (it seems to me the re
module is inspired by Perl's re's, so the similarity is very strong).

Often in Python there may be _better ways_ to perform tasks for which a
Perl-used developer automatically reaches for re's, but that's another
issue. When you're transliterating you can still use re's, then if need be
you do a "peephole cleanup" pass to get rid of the dispensable ones:-).


Alex

Alex Martelli

unread,
May 1, 2002, 3:08:22 AM5/1/02
to
James J. Besemer wrote:
...

> The basic regex operators are similar to Python's, though Perl adds some
> extras such as
>
> {n,m} # preceeding pattern matches at least n but no more than m
> {times

This tends to confirm my impression that people who consider Perl's re's
preferable may not fully understand Python's:

>>> a35=re.compile('^a{3,5}$')
>>> print a35.match('aa')
None
>>> print a35.match('aaa')
<_sre.SRE_Match object at 0x8186698>
>>> print a35.match('aaaa')
<_sre.SRE_Match object at 0x8186950>
>>> print a35.match('aaaaa')
<_sre.SRE_Match object at 0x8186960>
>>> print a35.match('aaaaaa')
None
>>>

Python re's imitate Perl's closely enough that this is a rather unPythonic
arrangement -- the upper bound is *included* (Python's ranges, slices etc
have lower-bound-included, upper-bound-excluded...).


Alex

Terry Hancock

unread,
Apr 30, 2002, 4:43:34 PM4/30/02
to
I was intrigued to find this was a serious discussion and
not a flame war. :-)

Cool -- I just learned a bit of Perl, which is probably
the reverse of most people's experience. Note that
Perl naivety is to be expected, therefore. However, I
narcissistically suppose that a reverse perspective
might be useful to somebody...

My frustration with Perl was that "arrays" and "hashes"
were very like "lists" and "dictionaries" except for
one critical point -- they don't allow nesting! (There
are more subtle differences too -- apparently Perl does
pretty much everything "by value" instead of
"by reference"). I'm not quite experienced enough
with either to fully appreciate the consequences of
this difference, but I know it must have interesting
consequences. However, I've started calling dictionaries
"hashes" in my head now -- I suppose that's not good,
but it seems more intuitive to me. "Dictionary" has
too strong a connection with the thing I use to look
up words in (whether paper or electronic).

Also, although Perl does apparently have "objects",
they aren't so easy as in Python. All of this has
led me to conclude that I will not be "switching" to
Perl anytime soon.

However, Perl does fill its "duct tape" roll pretty
well -- it's possible to compactly write simple
pieces of code to do quick fixes for various string
and file manipulations. It also does some common
tasks in nicely compact ways (such as the "process
all lines in all files mentioned on the command line,
or failing that, all the lines coming from stdin",
which is basically what "<>" means). Basically, it
seems to me that if all you ever do is write scripts
of 200 lines or less, Perl may serve you very well.

But if you're like me, and almost every program you
write quickly grows beyond 1000 lines, because you
can't resist adding new bells and whistles, or because
you are actually fusing a lot of your programs into
one or -- more often -- fusing a lot of other people's
programs (i.e. modules / "the batteries") to do a job,
then you'll quickly learn to love the objects, modules,
and superior data structures of Python. (Actually
Perl may have these structures, but they aren't obvious
enough to have been taught to me in learning basic Perl --
whereas in Python you learn and use them right away).

Which wording makes it clear that I took a class on Perl.
This was the only way for me to learn it. I learned Python
by myself in about a week, after which I was able to write
useful (if not elegant) programs. With Perl I tried this
and couldn't get over a fundamental resistence to learning
what seemed like arcane and annoying syntax. I finally
punted and signed up for a class, which I almost never
do. I suppose Perl is now the first programming language
I ever learned this way.

Lists in Python finally made me appreciate what Lisp
programmers were on about. As a long time number-crunching/
scientific applications programmer, in the Basic, Fortran,
C, Pascal tradition, I had little understanding of the
utility of things like lists, hashes or dictionaries,
and so forth. Python really sold me on them, though.

The regular expressions are nice too. There's a lot
of useful tasks that can be solved much more quickly
using them, "line noise" or no. Since I don't plan
to switch languages for any major project, the main
impact has been to increase my interest in using
Python's "re" module to solve similar problems.

Unfortunately, Python documenters seem to have a bit
of a chip on their shoulder about regular expressions,
whereas the main promoters of it have been long accustomed
to Perl. So most of the RE explanations have a definite
Perl bias. Python's implementation is a bit different,
so it can be tricky to learn (i.e. using Perl-centric
sources to learn Python's REs). Thus, while I'm sure
Python's RE implementation is "good" it may not be
"easy" by dent of being contrary to the only "texts"
I can find to learn it from (but see comments below).



Christopher Browne <cbbr...@acm.org> wrote:
> Mind you, I have found that the "More Pythonic Way" of constructing
> complex regexes by building components, like the following, to have
> merit:
>
> digit = '[0-9]'
> date = '\(' + digit + digit + digit + digit + '/' + digit + digit + '/'
> date = date + digit + digit + '\)'
>

> By building the regex out of something with named components, I don't
> have the horridness of line noise like:
> if ($line =~ /.*\s+\d+.\d+\s+\d+.\d+\s+.\d+.\d+/) {
>

> Ultimately, the answer is that both approaches have their own merits
> and demerits. The "Perl thing" tends to be shorter, while the "Python
> thing" tends to be more readable.

Thanks for the example -- I think there is some definite
merit to this. It occurs to me that you might be both more
clear and more compact (and equally pythonic?) to say:

digit = '[0-9]'
date = '\(' + 4*digit + '/' + 2*digit + '/' + 2*digit + '\)'

for the regular expression, so you don't have to count
the digits. That's starting to get kind of elegant, I
like it. Somehow it always helps me to be able to
pronounce my code. ;-D

At the risk of being terribly Python-centric, I think
Python feels like the "second implementation" of a
solution, where you have the benefit of hindsight to
help you design a simple, elegant, and powerful design
from the start, which you got by using the old, less
elegant solution which was simply the accumulation of
patches to your old problems -- which is what Perl
feels like. Given that Perl was indeed earlier, and
that experience with it has no doubt driven Python's
design, this may be no slight to Perl, in fact.

My Perl teacher described Perl as being "like English",
full of idioms and synonyms and ambiguities resolved
by context -- an organic, naturally evolved solution
to programming problems. If so, Python is probably like
Esperanto -- artificial, clean, regular, and easy to
learn, though perhaps not as creatively expressive in
itself.

One other odd observation -- I've noticed that Python
is very popular among computer graphics/graphic
artists, whereas Perl remains very popular among
musicians. This is a very unscientific, unsupported
observation -- but I noticed it when trying to find
both for a project I was working on. I have some
weird theories about why this might be so, but they're
probably wrong. :-)

Given that no one speaks computer languages natively,
the huge difference in learning curve between Esperanto,
which was designed for it, and English (I have only
pity for those who are forced to learn it as a foreign
language -- I've tried to do penance by studying Japanese,
but frankly even that is more logical), is surely
an argument in Python's favor. (In all fairness, I
should admit that I've never actually tried to learn
Esperanto, which is not so popular in America. Also,
it will always be associated with Red Dwarf and
Rimmer for me).

IMHO, of course...

Terry

--
------------------------------------------------------
Terry Hancock
han...@anansispaceworks.com
Anansi Spaceworks
http://www.anansispaceworks.com
------------------------------------------------------


Alex Martelli

unread,
May 1, 2002, 5:22:35 AM5/1/02
to
Terry Hancock wrote:
...

> tasks in nicely compact ways (such as the "process
> all lines in all files mentioned on the command line,
> or failing that, all the lines coming from stdin",
> which is basically what "<>" means). Basically, it

Python's equivalent, "for line in fileinput.input():",
seems quite good to me -- just one more case of:

>> The "Perl thing" tends to be shorter, while the "Python
>> thing" tends to be more readable.


Alex

Andrew Dalke

unread,
May 1, 2002, 5:26:48 AM5/1/02
to
Alex:

> >>> a35=re.compile('^a{3,5}$')
> ...

> >>> print a35.match('aaaaa')
> <_sre.SRE_Match object at 0x8186960>
> >>> print a35.match('aaaaaa')
> None
> >>>
>
> Python re's imitate Perl's closely enough that this is a rather unPythonic
> arrangement -- the upper bound is *included* (Python's ranges, slices etc
> have lower-bound-included, upper-bound-excluded...).

But it isn't a range, it's a repeat count. Otherwise people would
also expect

^a{0}

to match "" because that contains 0 "a"s. As such, it's much more
similar to
"a" * 3 == "aaa"
"a" * 5 == "aaaaa"

Andrew
da...@dalkescientific.com

Andrew Dalke

unread,
May 1, 2002, 5:39:52 AM5/1/02
to

Terry Hancock:

>Thanks for the example -- I think there is some definite
>merit to this. It occurs to me that you might be both more
>clear and more compact (and equally pythonic?) to say:
>
>digit = '[0-9]'
>date = '\(' + 4*digit + '/' + 2*digit + '/' + 2*digit + '\)'
>
>for the regular expression, so you don't have to count
>the digits.

This comes from my Martel project
(http://www.dalkescientific.com/Martel)

>>> from Martel import Time
>>> Time.make_pattern("%(YYYY)/%(MM)/%(DD)")
'(?P<year?type=long>[0-9]{4})\\/(?P<month?type=numeric>(0[1-9]|1[012]))\\/(?
P<day?
type=numeric>(0[1-9]|[12][0-9]|3[01]))'
>>> print Martel.select_names(Time.make_expression("%(YYYY)/%(MM)/%(DD)"),
())
[\d]{4}\/(0[1-9]|1[0-2])\/(0[1-9]|[12][\d]|3[01])
>>>

The first one uses an extension to regular expressions to allow XML-style
key/value pairs on the match names. The second one makes an regexp parse
tree I can manipulate -- in this case to remove all named groups.

This solution is even nicer in some sense because it's easy to
read and it doesn't allow

1234/56/78

as a legal year.

>My Perl teacher described Perl as being "like English",
>full of idioms and synonyms and ambiguities resolved
>by context -- an organic, naturally evolved solution
>to programming problems. If so, Python is probably like
>Esperanto -- artificial, clean, regular, and easy to
>learn, though perhaps not as creatively expressive in
>itself.

Oh my, not this argument again. Before people respond,
there's been discussions on the English/Esperanto comparison
before. Please check the archives.

Andrew
da...@dalkescientific.com

Fredrik Lundh

unread,
May 1, 2002, 6:09:02 AM5/1/02
to
James J. Besemer wrote:

> The basic regex operators are similar to Python's, though Perl
> adds some extras such as
>
> {n,m} # preceeding pattern matches at least n but no more than m times

how is that different from Python's

{m,n}

Causes the resulting RE to match from m to n repetitions
of the preceding RE, attempting to match as many repetitions
as possible. For example, a{3,5} will match from 3 to 5 "a"
characters.

(see http://www.python.org/doc/current/lib/re-syntax.html)

</F>


Steve Holden

unread,
May 1, 2002, 7:42:08 AM5/1/02
to
"Patrick W" <quite...@yahoo.com.au> wrote in message
news:826628e...@acropolis.localdomain...

Speaking as someone who bought a house just over a year ago, I'd be very
surprised if the builder *had* apprentices, and even more surprised if any
of them could pronounce "wheelbarrow".

Seems to me that the IT industry would be a fruitful place to reintroduce
the concepts of the mediaeval apprenticeship.

buut-only-if-i-get-to-be-master-ly y'rs - steve
--

Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/

Alex Martelli

unread,
May 1, 2002, 8:29:29 AM5/1/02
to
Andrew Dalke wrote:
...

>> unPythonic arrangement -- the upper bound is *included* (Python's ranges,
>> slices etc have lower-bound-included, upper-bound-excluded...).
>
> But it isn't a range, it's a repeat count. Otherwise people would
> also expect
>
> ^a{0}
>
> to match "" because that contains 0 "a"s. As such, it's much more

"Otherwise"...?

>>> a0=re.compile('^a{0}')
>>> a0.match('')
<_sre.SRE_Match object at 0x8187fb0>

Of *course* a{0} matches '' -- how could it FAIL to?


Alex

Roy Smith

unread,
May 1, 2002, 8:08:03 AM5/1/02
to
"Billy Ng" <kwo...@earthlink.net> wrote:
> I am also new to python. I think python will be my replacement of perl.
> However, if I need to do very heavy regular expression, I still prefer perl.
> I just don't feel comfortable with the python's re syntax.

Granted, it's a little more verbose to say:

m = re.match (...)
if m:
blah = m.group (1)

then to do

if (m/.../) {
blah = $1;
}

but not much. On the other hand, I've been burned several times by failing
to keep track of when $1 goes out of scope (or maybe "automagically gets
redefined" is a better way of putting it?). If you've got to save all the
$'s in new variables immediately after the regex, the perl version can
easily get more verbose than python, since everything is tucked away in the
match object, and stays there for as long as you need it.

Cameron Laird

unread,
May 1, 2002, 10:02:40 AM5/1/02
to
In article <826628e...@acropolis.localdomain>,

It's a good point. I think Mr. Melson's also
right, though. And my understanding of at
least some traditions of apprenticeship is
that they *do* call for the juniors to learn
two wheelbarrows before using either.

I'll try to make this more precise in the
case at hand. You are right that it's con-
siderably more expensive to learn two
languages, or a mix of two languages, than
a single one. One has to expect that there's
a far greater return-on-investment for
learning the first, than the second. This
puts a premium, of course, on making a cor-
rect choice for the first.

So far, we're conversing rather abstractly.
In the specific case of Perl vs. Python, I
contend that:
1. their functional roles are quite
similar;
2. both languages are "lightweight"
in the sense that one can start
to use them with only a few hours
spare time; and
3. their "subjective" applicability
is rather polarized.
What I mean by the latter is that a large
number of engineers seem to have big emotional
reactions to syntactic differences that are
superficial in any language-theoretic sense:
significant white-space, variable markers,
function argument lists, CPAN vs. distutils,
and so on.

My conclusion: *experience* both languages
(a modest investment), decide for yourself the
"first impression" each makes, pick the one
that feels right, then *learn* that language,
with confidence that you're missing little by
choosing only that one.

Mark McEahern

unread,
May 1, 2002, 9:58:50 AM5/1/02
to
[James J. Besemer]

> Superior probably is too strong a word, though regex in Perl is a
> little easier to get to right out of the box. I.e, regex is part
> of Perl's "builtins".

Thank you for your response. I'm not terribly familiar with Python's re
module, but I'll see if I can duplicate the examples you provided...

> PERL regex example:
>
> # No import, compile, function or object syntax.
> # Implied match is with the "current" thingy ( $_, IIRC)

As others have remarked, I prefer the explicitness of Python's re
module--you have to import it to use it.

>
> action() if /regex/ ; # perform action() if regex match

Well, literally speaking, as far as I know there's no Python equivalent to
this. To get a sense of why, you can type "import this" into the Python
interactive interpreter. ;-)

Nonetheless, you can do the equivalent fairly easily by explicitly
specifying the string you want to match:

import re
s = "Explicit is better than implicit."
pat = re.compile("licit")
if pat.search(s):
action()

> To match with a specific object, say, a variable you use the "=~"
> operator.
>
> action( $a) if $a =~ /regex/ ; # perform action if regex matches $a

I think the same Python example above covers this situation.

> Note that the statement for substitute is like the "vi" command:
>
> $a ~ s/old/new/gi if $a =~ /pattern1/;
>
> # substitue "new" for "old" in $a if $a matches pattern1
> # g suffix for global replacement
> # i suffix for case insensitive comparison

You can use the re.sub() to replace count occurrences of a pattern:

import re
s = "Explicit is better than implicit."
old = re.compile("e", re.IGNORECASE)
new = "f"
count = 1
if pat.search(s):
s2 = re.sub(old, new, s, count)
print s2

Not specifying count means replace 'em all.

> The basic regex operators are similar to Python's, though Perl
> adds some extras such as
>
> {n,m} # preceeding pattern matches at least n but no more
> than m times

Python has that too:

http://www.python.org/doc/current/lib/re-syntax.html

> A successful match sets a flurry of global variables:
>
> $& = the matched portion of the input string
>
> $` = everything before the match
>
> $' = everything after the match

Thank Crom Python doesn't do that. As someone else mentioned, these things
are tucked away into match objects, if you want them, rather than being
squirted into your namespace.

> Parentheses in the regex break the matching pattern into "groups" and the
> portions of the string coresponding to each group may be accessed via:
>
> $1, $2, ...
>
> E.g.,
>
> s/^([^ ]* *([^ ]*)/$2 $1/; # reverse order of 2 words

This switches the first and last words of a sentence. I didn't bother
putting the period back in there or sentence-casing the new first word.

import re
s = "Explicit is better than implicit."
pat = re.compile("^(\w+)(.* )(\w+)\.$")
m = pat.search(s)
if m:
print "%s%s%s" % (m.groups()[2], m.groups()[1], m.groups()[0])

> if( /Time: (..):(..):(..)/ ){ # extract hh:mm:ss fields
> $hours = $1;
> $min = $2;
> $sec = $3;
> }

Here's a case where Python's ability to name groups is interesting:

import re, time
t = time.asctime()
pat = re.compile("(?P<hour>\d{2})\:(?P<minute>\d{2})\:(?P<second>\d{2})")
m = pat.search(t)
if m:
print m.group('hour')
print m.group('minute')
print m.group('second')
else:
print "Not found."

Cheers,

// mark

Fredrik Lundh

unread,
May 1, 2002, 10:38:21 AM5/1/02
to
Mark McEahern wrote:
> Here's a case where Python's ability to name groups is interesting:
>
> import re, time
> t = time.asctime()
> pat = re.compile("(?P<hour>\d{2})\:(?P<minute>\d{2})\:(?P<second>\d{2})")
> m = pat.search(t)
> if m:
> print m.group('hour')
> print m.group('minute')
> print m.group('second')
> else:
> print "Not found."

(you don't need to escape colons)

also note that if you pass multiple group numbers (or names)
to the group method, it returns the given matches as a tuple:

m = re.search("(\d{2}):(\d{2}):(\d{2})", t)
if m:
hour, minute, second = m.group(1, 2, 3)

(down from five lines in the original perl example ;-)

</F>


Fredrik Lundh

unread,
May 1, 2002, 10:41:55 AM5/1/02
to
Mark McEahern wrote:

> This switches the first and last words of a sentence. I didn't bother
> putting the period back in there or sentence-casing the new first word.
>
> import re
> s = "Explicit is better than implicit."
> pat = re.compile("^(\w+)(.* )(\w+)\.$")
> m = pat.search(s)
> if m:
> print "%s%s%s" % (m.groups()[2], m.groups()[1], m.groups()[0])

instead of using groups three times, you can pass multiple
arguments to the group method:

m = pat.search(s)
if m:

print "%s%s%s" % (m.group(3, 2, 1))

or you can use group references in the sub method:

print pat.sub(r"\1\2\3", s)

</F>


Alex Martelli

unread,
May 1, 2002, 10:58:21 AM5/1/02
to
Cameron Laird wrote:
...

> number of engineers seem to have big emotional
> reactions to syntactic differences that are
> superficial in any language-theoretic sense:
> significant white-space, variable markers,

Sorry, but I cannot agree that "variable markers" (stropping of names to
indicate role) is "superficial in any language-theoretic sense". In
Python, any name (simple or compound) can refer to any kind of object, and
knowing about such 'kind' issues is the role of the object (not of the
name, not of the compiler, not necessarily of the programmer). This IS a
deep difference wrt a language where the programmer must annotate (e.g.,
strop) names to tell the compiler about what kind of object they "contain"
(or "refer to", but Perl has value-semantics as its basis, not reference
semantics like Python), explicitly annotate referencing and dereferencing
as well, and so on.

It may or may not be worth superficially learning both Perl and Python
before going in depth into either (if it is, then I think Ruby should also
be in the mix). But "variable markers" are still quite a deep difference.


Alex

Fredrik Lundh

unread,
May 1, 2002, 11:02:18 AM5/1/02
to
> or you can use group references in the sub method:
>
> print pat.sub(r"\1\2\3", s)

which should have been:

print pat.sub(r"\3\2\1", s)

</F>


Bob Melson

unread,
May 1, 2002, 10:56:37 AM5/1/02
to
In article <tq7naa...@127.0.0.1>,
Carl Banks <imb...@vt.edu> writes:
> "Bob Melson" wrote:
>> In article <aamjat$qku$1...@panix1.panix.com>,
>> aa...@pythoncraft.com (Aahz) writes:
>>> In article <mailman.1020147892...@python.org>,
>>> Andrew McNamara <and...@object-craft.com.au> wrote:
>>>>
>>>>I'd go as far as to say the
>>>>sendmail.cf language is simpler, easier to learn and maintain than perl.
>>>
>>> .sigfile?
>>
>> Look at it this way -- you pick the best language tool to do the job at
>> hand. If python is the better language for that job, you use python; if
>> it's perl, then you use perl; if it's some other language, you use _that_
>> language. If you're asked to build a house, you certainly don't confine

>> yourself to a single tool -- you use the tools appropriate to the job you
>> have to do; why should it be different with scripting languages?
>
>
> So you agree that he shouldn't bother with Perl.
>
>
Nope.

Bob

Bob Melson

unread,
May 1, 2002, 10:55:47 AM5/1/02
to
In article <aan2ll$ib6$1...@panix1.panix.com>,
aa...@pythoncraft.com (Aahz) writes:
> In article <aamm5k$kv3$1...@bubba.NMSU.Edu>,

> Bob Melson <"mel...@earthlink.net"> wrote:
>>
>>Look at it this way -- you pick the best language tool to do the job at
<snip>
> Fine sentiment. Now, under what circumstances would you recommend Perl
> over Python?

Kinda hard to say. In general, however, I'd say that _I_ would be inclined
to use perl in preference to python where there's no significant advantage
to be derived from python's OO features.

Bob Melson

Alex Martelli

unread,
May 1, 2002, 11:07:58 AM5/1/02
to
Mark McEahern wrote:
...

>> s/^([^ ]* *([^ ]*)/$2 $1/; # reverse order of 2 words
>
> This switches the first and last words of a sentence. I didn't bother
> putting the period back in there or sentence-casing the new first word.
>
> import re
> s = "Explicit is better than implicit."
> pat = re.compile("^(\w+)(.* )(\w+)\.$")
> m = pat.search(s)
> if m:
> print "%s%s%s" % (m.groups()[2], m.groups()[1], m.groups()[0])

I suspect a closer match to the quoted perl code's intentions is:

s = re.sub(r'^(\S+)(\s+)(\S+)', r'\3\2\1', s)

though it's a bit hard to tell because it seems to me that neither the
original Perl (parentheses unbalanced) nor your Python (works on 1st
and last rather than first two words; uses wordcharacters rather than
white/nonwhite distinction) are correct.


Alex

François Pinard

unread,
May 1, 2002, 10:43:27 AM5/1/02
to
[Aahz]

> Now, under what circumstances would you recommend Perl over Python?

Perl is especially suited for running Randall Schwartz' one-liners! But over
four or five Perl lines, you'd probably be better off with Python! :-) :-)

--
François Pinard http://www.iro.umontreal.ca/~pinard

Mark McEahern

unread,
May 1, 2002, 10:31:00 AM5/1/02
to
[bru...@tbye.com]
> IMO this is what makes the Python way a Good Thing - that tiny bit of
> extra effort required to use them (hopefully) makes a person stop and
> consider if re's really are the right tool. It's pretty common to have
> someone wondering how to reduce the complexity and/or improve the
> performance of their re and have the answer be "don't use an re" or "do
> more of the work outside the re".

What's that saying? It goes something like,

Suppose you have a problem that you think requires regular expressions. Now
you have two problems.

;-)

// mark

bru...@tbye.com

unread,
May 1, 2002, 11:10:10 AM5/1/02
to
On Wed, 1 May 2002, Christopher Browne wrote:

> > Could you give us a concrete example where the use of regular expressions in
> > Perl is superior to Python?
>
> Well, in Perl, they're "first class objects," as it were, requiring no
> extra references to functions to get them to function, as a base part
> of the language syntax.

IMO this is what makes the Python way a Good Thing - that tiny bit of

extra effort required to use them (hopefully) makes a person stop and
consider if re's really are the right tool. It's pretty common to have
someone wondering how to reduce the complexity and/or improve the
performance of their re and have the answer be "don't use an re" or "do
more of the work outside the re".

Just yesterday a Java guy was asking me to help him speed up his re that
found Wiki names from a list of tokens. The first optimization was to not
even call the re engine unless the token began with a capital letter. The
next optimization was to see if the rest of the string matched the
lowercase version of the rest of the string, and if not, consider it a
Wiki name, so in the end he didn't use re's at all (he had a slightly
liberal definition of a Wiki name).

When using a regular expression is the right solution, they are extremely
powerful and elegant, so I understand the temptation to use them all over
the place (I'm suspicious when people tell me they're using regular
expressions "all the time" - sometimes it's for valid reasons, but often
it's not).

> Mind you, I have found that the "More Pythonic Way" of constructing
> complex regexes by building components, like the following, to have
> merit:
>
> digit = '[0-9]'
> date = '\(' + digit + digit + digit + digit + '/' + digit + digit + '/'
> date = date + digit + digit + '\)'

Just a side note, you can make this even more readable:

digit = '[0-9]'


date = '\(' + 4*digit + '/' + 2*digit + '/' + 2*digit + '\)'

-Dave

Patrick W

unread,
May 1, 2002, 11:51:47 AM5/1/02
to
cla...@starbase.neosoft.com (Cameron Laird) writes:
>
> [...] You are right that it's con-

> siderably more expensive to learn two
> languages, or a mix of two languages, than
> a single one. One has to expect that there's
> a far greater return-on-investment for
> learning the first, than the second. This
> puts a premium, of course, on making a cor-
> rect choice for the first.

Indeed. I'm sure you understand me, but let me elaborate:

import IMHO and sprinkle it liberally throughout.

A programmer ought to know at least four languages in depth. If those
four languages are well chosen, they can last a lifetime. If they lack
certain features that come pre-packaged elsewhere, it's far better to
acquire the _concepts_ and _techniques_ implicit in them, and
implement them in your chosen language(s), as opposed to madly
accumulating new notations simply because they possess a convenient
feature or two.

I think this popular notion of "right tools for the right job" is
actually very harmful, both to individuals and to the science/industry
as a whole. To stick with the tradesman metaphor for a moment, I think
it creates a culture in which programmers are encouraged to become
"jack of all trades, master of none." Resumes may be stuffed full of
impressive sounding acronyms, but programmers actually don't know as
much as they once did. It's not because we're stupid (although the
barrier to entry is considerably lower these days); it's partly a
result of having too many alternative implementation details to
learn. When depth is sacrified for breadth, beyond a certain point, it
becomes a very bad thing.

To make sensible choices up front, and to focus on a few languages and
topics to the exclusion of many others is the only way to go. That's
why I reject this "learn them both" approach, unless the languages are
different enough in purpose and style and philosophy to make them both
worthwhile and complementary.

So, choice is necessary, but what to choose?

IMHO, the best choices for starters are:

* One of [C, C++] for maximum efficiency, minimal overhead and an
understanding of the low-level foundations of higher level
facilities.

* One of [Python, Perl, Python, Ruby, Python, Tcl, Python] for general
purpose programming and scripting. For my money, Python is the clear
winner in this category. It's great for everything from text
processing and os scripting through to graphics, multimedia, comms,
database programming, web development, etc. It's just as much fun
for skilled hackers as it is for beginners.

* Something that encourages a different style of thinking. My own
favourite (for this purpose) is Lisp. I feel that Lisp is powerful
enough to handle anything I'll ever throw at it, and it's flexible
enough to incorporate any new programming paradigms that computer
scientists are brilliant (or crazy, or foolish) enough to think up.

* Whatever else turns you on.

> So far, we're conversing rather abstractly.
> In the specific case of Perl vs. Python, I
> contend that:
> 1. their functional roles are quite
> similar;
> 2. both languages are "lightweight"
> in the sense that one can start
> to use them with only a few hours
> spare time; and

Yes.

> 3. their "subjective" applicability
> is rather polarized.
>

> [ trimmed ]


>
> My conclusion: *experience* both languages
> (a modest investment), decide for yourself the
> "first impression" each makes, pick the one
> that feels right, then *learn* that language,
> with confidence that you're missing little by
> choosing only that one.

Absolutely. Then extend it with concepts and techniques from many
other sources. There's far more value in that than in learning a new
notation every few months (provided the initial choices are good
ones).

Jeff Epler

unread,
May 1, 2002, 12:50:31 PM5/1/02
to
> Centuries ago, Nostradamus foresaw when "Mark McEahern" <mark...@mceahern.com> would write:
> > Could you give us a concrete example where the use of regular expressions in
> > Perl is superior to Python?
>
On Wed, May 01, 2002 at 01:02:07AM -0400, Christopher Browne wrote:
> Well, in Perl, they're "first class objects," as it were, requiring no
> extra references to functions to get them to function, as a base part
> of the language syntax.

I always thought that "first class" meant a type of object that can
be passed as an argument in a function.[1] In that sense, Python REs
(as well as almost everything else in Python -- functions, instances,
bound methods, ...) are first-class, because you can write

def group(x): return r'\(' + x + r'\)

digit = "[0-9]"
date = group(digit * 4 + "/" + 2*digit + "/" + 2 * digit)
date_re = re.compile(date)

w = some_graphical_widget()

w.set_valid_format(date_re)

In Perl, I'm pretty sure that
&some_sub(/\(\d\d\d\d\/\d\d\/\d\d\)/);
does not pass a regular expression into some_sub, it passes the result
of matching that RE with the contents of $_.

Jeff
[1] From http://www.owlnet.rice.edu/~comp210/97fall/Labs/lab06/
First-class functions

The term first-class refers to the idea that values can be

* part of data structures,
* formed at run-time,
* arguments to functions, and
* returned by functions.
It's often said that functions are first-class in C (well, at least I've
heard it said) since they can be part of data structures, be passed to
functions or returned by them. However, they cannot be formed at
runtime in C, so they may not be "first class" in the most stringent
sense.


Andrew Dalke

unread,
May 1, 2002, 1:27:52 PM5/1/02
to
Alex:

> "Otherwise"...?
>
> >>> a0=re.compile('^a{0}')
> >>> a0.match('')
> <_sre.SRE_Match object at 0x8187fb0>
>
> Of *course* a{0} matches '' -- how could it FAIL to?

Oops, silly me. I was posting way after my bedtime. :)

What I meant to say was that if range was to be more Pythonic
("lower-boud-included, upper-bound-excluded") then the single
element repeat count should also be made more Pythonic.

Consider then if
s = "aaaaa"
in this case,
s[0] == "a"
which means the equivalent repeat would be
^a{0}$
to match "a" and only "a"

But people interpret that as a repeat count (like "a" * 1) rather
than as a slice of sort and it hasn't been a problem. At least,
I've not seen people surprised by it.

I therefore don't think people have a Pythonic slice expectation
for the {,} construct in regexps. On the other hand, there aren't
that many people who use this in the first place, so that population
is somewhat self selected.

Andrew
da...@dalkescientific.com

Aahz

unread,
May 1, 2002, 2:06:44 PM5/1/02
to
In article <aaovlj$agm$1...@bubba.NMSU.Edu>,

Bob Melson <"mel...@earthlink.net"> wrote:
>In article <aan2ll$ib6$1...@panix1.panix.com>,
> aa...@pythoncraft.com (Aahz) writes:
>> In article <aamm5k$kv3$1...@bubba.NMSU.Edu>,
>> Bob Melson <"mel...@earthlink.net"> wrote:
>>>
>>>Look at it this way -- you pick the best language tool to do the job at
>>
>> Fine sentiment. Now, under what circumstances would you recommend Perl
>> over Python?
>
>Kinda hard to say. In general, however, I'd say that _I_ would be inclined
>to use perl in preference to python where there's no significant advantage
>to be derived from python's OO features.

Can you provide a non-contrived example, given that you're attempting to
advise someone who knows neither Perl nor Python?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"I used to have a .sig but I found it impossible to please everyone..." --SFJ

geek

unread,
May 1, 2002, 2:14:56 PM5/1/02
to
Then <aaovlj$agm$1...@bubba.NMSU.Edu>, spoke up and said:

> Bob Melson <"mel...@earthlink.net"> wrote:
> >Kinda hard to say. In general, however, I'd say that _I_ would be inclined
> >to use perl in preference to python where there's no significant advantage
> >to be derived from python's OO features.
>
> Can you provide a non-contrived example, given that you're attempting to
> advise someone who knows neither Perl nor Python?

My rule is simply: if there's no good reason to use !Python, use
Python. Now, what's a good reason not to use Python?
1) standalone project, the coder doesn't know Python but does know
$scripting_language fairly well.
2) large body of existing work, not in Python, which will not be
ported to Python.

Yes, these are simplistic. For instance, if the "large body of work"
consists mostly of C/Fortran libraries, I'd be tempted to SWIG it and
use Python.

Aahz

unread,
May 1, 2002, 2:18:03 PM5/1/02
to
In article <mailman.1020263523...@python.org>,

Mark McEahern <mark...@mceahern.com> wrote:
>
>What's that saying? It goes something like,
>
>Suppose you have a problem that you think requires regular expressions. Now
>you have two problems.

'Some people, when confronted with a problem, think "I know, I'll use regular
expressions". Now they have two problems.' --Jamie Zawinski, comp.lang.emacs

Paul Rubin

unread,
May 1, 2002, 2:18:49 PM5/1/02
to
aa...@pythoncraft.com (Aahz) writes:
> Fine sentiment. Now, under what circumstances would you recommend Perl
> over Python?

One feature of perl that Python lacks is the -T (taint checking) flag.
I always use it when writing web cgi's in perl and it frequently
catches something I missed. In general, Perl's designers seem more
sensitive to these security issues and Python has dangerous
constructions that would never have been allowed in perl.
Examples include the "smart cookie" class and the input() function
(which eval's the input string).

Bernhard Herzog

unread,
May 1, 2002, 2:39:19 PM5/1/02
to
aa...@pythoncraft.com (Aahz) writes:

> In article <mailman.1020263523...@python.org>,
> Mark McEahern <mark...@mceahern.com> wrote:
> >
> >What's that saying? It goes something like,
> >
> >Suppose you have a problem that you think requires regular expressions. Now
> >you have two problems.
>
> 'Some people, when confronted with a problem, think "I know, I'll use regular
> expressions". Now they have two problems.' --Jamie Zawinski, comp.lang.emacs

TINCLE (There is no comp.lang.emacs) :)

At least not on google. And googling for "comp.lang.emacs" only turns up
this JWZ citation.

The posting was on comp.emacs.xemacs and alt.religion.emacs:
http://groups.google.com/groups?selm=33F0C496.370D7C45%40netscape.com

Bernhard

--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://www.mapit.de/

Ian Bicking

unread,
May 1, 2002, 4:21:20 PM5/1/02
to
A few minor additions:

On Wed, 2002-05-01 at 08:58, Mark McEahern wrote:
> > A successful match sets a flurry of global variables:
> >
> > $& = the matched portion of the input string
> >
> > $` = everything before the match
> >
> > $' = everything after the match
>
> Thank Crom Python doesn't do that. As someone else mentioned, these things
> are tucked away into match objects, if you want them, rather than being
> squirted into your namespace.

In particular, if you do:
match = someRegex.search(s)
match.group(0) # Like $&
s[:match.start()] # Like #`
s[match.end():] # Like #'
match.group(x) # Like $x, where x is a number

Probably for any $ variable in Perl, there will be a fairly simple way
of getting the same result in Python.

> > Parentheses in the regex break the matching pattern into "groups" and the
> > portions of the string coresponding to each group may be accessed via:
> >
> > $1, $2, ...
> >
> > E.g.,
> >

> > s/^([^ ]* *([^ ]*)/$2 $1/; # reverse order of 2 words
>
> This switches the first and last words of a sentence. I didn't bother
> putting the period back in there or sentence-casing the new first word.
>
> import re
> s = "Explicit is better than implicit."
> pat = re.compile("^(\w+)(.* )(\w+)\.$")
> m = pat.search(s)
> if m:
> print "%s%s%s" % (m.groups()[2], m.groups()[1], m.groups()[0])

Or you can do:

regex = re.compile(r'^([^ ]* *([^ ]*)')
transposed = regex.sub(lambda m: "%s %s" % (m.group(2), m.group(1)), s)

This is closer to the Perl example. The lambda may leave it a bit
difficult to read, though :) There must be something like
substitute-base-on-a-function in Perl, but it should be noted that while
it can be more awkward in some cases, it's also much more powerful than
the simple s/.../$2 $1/; substitution. For instance, a very simple
templating system can be:

templateRE = re.compile(r'%%(.*?)%%')
def subTemplate(source, valueDict):
return templateRE.sub(lambda m, valueDict=valueDict: valueDict.get(
m.group(1), ''), source)


Ian


James J. Besemer

unread,
May 1, 2002, 6:25:03 PM5/1/02
to

Fredrik Lundh wrote:

> > {n,m} # preceeding pattern matches at least n but no more than m times
>
> how is that different from Python's
>
> {m,n}

No different.

Simple brain fart, having forgotten that it was in Python too.

Regards

--jb

--
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:j...@cascade-sys.com


James J. Besemer

unread,
May 1, 2002, 6:43:09 PM5/1/02
to

Mark McEahern wrote:

> As others have remarked, I prefer the explicitness of Python's re
> module--you have to import it to use it.

I absolutely agree.

Among other things, Python allows alternative implementations of RE, while Perl
has just 1 standard (IIRC, they may have some alternative RE packages, for
backwards compatibility or something).

Furthermore, compiled regular expressions is a natural property of Python's
implementation but I could not figure out how to do that in Perl (if it's
possible at all (I seem to recall it was somehow but could not find a
referenc)).

Let me emphasize that I did NOT at all intend to show Perl's SUPERORITY. I
said it was too strong a word. I just wanted to illustrate how Perl did things
and that regex is "builtin" to the language. FWIW, I've read at least one
published comparison of Perl vs. Python and the writer ended up picking Perl by
a small margin and the greater number of turn-key features (larger set of
builtins) was what tilted the scale.

Anyway, I wrote to damn Perl, not praise it. With a conscious effort to avoid
sarcasm, I thought the examples would speak for themselves -- in provoking a
gag reflex, if nothing else.

I certainly agree with all of Mark's comments and criticisms about the Perl
examples. In particular, I never cared for Perl's notion of "default"
operands, as I could never keep straight what the default was in different
contexts.

Finally, it was a careless omission on my part to imply that Python regex
lacked the "{n,m}" pattern. Thanks to all who pointed it out.

François Pinard

unread,
May 1, 2002, 7:27:54 PM5/1/02
to
[Patrick W]

> IMHO, the best choices for starters are:
> * One of [C, C++]

> * One of [Python, Perl, Python, Ruby, Python, Tcl, Python]

> * Something that encourages a different style of thinking. [Lisp]


> * Whatever else turns you on.

Excellent advice and analysis, congratulations!

I guess programmers should all get acquainted in their life with some
non-procedural language. As some people are not inclined toward inference
engines :-), one could aim languages like `SQL', non-procedural enough!

About `C++'... I once asked a someone, who specialised in languages,
what was his opinion about `C++', and he laconically replied: `Simula--'.
He was right in that `C++' looks like a half-hearted cross between `C' and
`Simula'. But Simula went out of fashion, while `C++' is still in the air.

`Lisp' (my preferred one is `Scheme', yet some people take offence when
`Scheme' is presented as a `Lisp') encourages a different style of thinking,
but still, it is an imperative, procedural language, like `C' and `Python'.

Terry Hancock

unread,
May 1, 2002, 9:14:41 AM5/1/02
to
From: geek <ge...@andrew.cmu.edu>
Organization:
> Then <aaovlj$agm$1...@bubba.NMSU.Edu>, spoke up and said:
> > Bob Melson <"mel...@earthlink.net"> wrote:
> > >Kinda hard to say. In general, however, I'd say that _I_
> would be inclined
> > >to use perl in preference to python where there's no
> significant advantage
> > >to be derived from python's OO features.
> >
> > Can you provide a non-contrived example, given that you're
> attempting to
> > advise someone who knows neither Perl nor Python?
>
> My rule is simply: if there's no good reason to use !Python, use
> Python. Now, what's a good reason not to use Python?

I've got practical examples: I sometimes use Perl as a
"super-sed". The original sed's REs are getting quite
out of date, so it's kind of nice to use Perl's. Doing
the same thing in Python is quite feasible, but will probably
take about an hour longer to make work, because you have
to get the import right, compile the regex and figure out
how to get data in and out of the program. All easy stuff,
but extra lines of code, and if you're thumbfingered with
the RE module it takes some time to get right.

If the project was going to take five minutes to write in
Perl, then that's about 1200% overhead. Particularly
nasty if the lifetime of use is another ten minutes.

In developing a web app in Python/Zope I needed a bunch
of image-buttons. They are color coded -- or rather
color-scheme coded because they are anti-aliased.

I used ImageMagick's convert to pipe the GIFs out to an
XPM which is a readable, palette-based format (open it
in gvim if you want to see a cool example of syntax
highlighting). Anyway, I can easily use a regex to
swap the color patterns around in the palette, e.g.:

perl -pe 's/(00)([0-9a-f][0-9a-f])00/\2\2\1/' green.xpm > yellow.xpm

(Now loop that over a couple hundred files, either in Perl,
or as I did, using tcsh's foreach. Then change colors and
loop again.).

That would've taken a bit longer in Python, and it's doubtful
I would recoup the investment (though I probably spent more
on this email ;-D ). It's not foolproof -- it won't catch
named colors, for example, only numerical ones. But it
was good enough and fast enough.

A slightly less trivial example was a problem in which my
partner had recorded a bunch of business transactions in
a comma-separated list in what turned out to be the wrong
order. She wanted to flip everything around and compute
sums over it. We aren't planning on standardizing on this
format or anything -- we just haven't gotten a spreadsheet
or database solution that works for this yet. April 15th
was pressing and we just needed to get the stats ready for
it (this is the Income Tax deadline in the US). I spent
about 30 minutes and got the output to work using Perl.
It was not particularly elegant, but only took about
10-20 lines of code. It was highly dependent on observable,
but unintended coincidences in the data, such as the
use of metric date order which causes string sorts to
be equivalent to date sorting. It was however, noticeably
faster than computing it all with a hand-calculator. It
was also a good decision, since we actually had to alter
it 3-4 times to get the correct answer (this would've
taken 2-3 hours on a calculator, because the entire
process would have to be repeated).

The same thing would've taken me 3-4 hours in Python
and about 40-50 lines of code. I would have had a much
nicer program though -- one I'd have been able to
incorporate or make permanent if I needed to. If we
were even considering standardizing on data like this,
I'd have used Python.

It seems to me that (with considerable training overhead)
Perl allows you to make these extremely short utterances
of code which do very clever things, do them quickly,
and with little development time (e.g. on the order of
the single usage time, as above). On the other hand,
it doesn't analyze well. I probably won't remember what
exactly I did when tax time comes next year, and the
coincidences that the above code depended on may not
be there. On the other hand, by then I won't need it
anymore, because the data will be in a different format.

This is what I meant by "duct tape role" in my previous
posting.

On the other hand, if I'd never learned Perl, I could
probably do all of the above in Python. But I might've
opted to just do it manually in some cases. That would've
been a loss, though, as I would actually have underestimated
the cost of doing it manually in both of these examples
(both times I expected to get it right the first time,
but actually repeated it 3-4 times until I was satisfied --
at a cost of only a couple of minutes for each retry,
since I had used a program).

The problem of course, is that this kind of underestimation
happens a lot. In particular, a program you write to
solve one problem is frequently one you realize later
would be useful for something else. And then you want
to add stuff to it. With Perl this would get you into
trouble quickly, whereas Python encourages you to use
more sensible design and you usually wind up with something
you *can* reuse.

My biggest argument for Python though, is that it is
the only language I can program in while being interrupted
by small children! I don't know why, though I theorize
that it's because of the explicit readability, but I
can "recover state" much faster with Python than with
any other language I've tried (including, but not limited
to Perl), which generally require me to maintain very
high levels of focus to code.

When you're being interrupted every 1-5 minutes by a
diaper emergency, spilled oatmeal, or urgent reports from
"Planet Iima", this becomes a non-trivial concern. If
it takes you typically 5-minutes to recover your focus,
it can quickly be seen that your productivity will plummet
to near zero, while if you can recover in 30-seconds or
so, you'll be at 50-90% efficiency, which is not too
bad. I assert that this environment is the severest
test of mental discipline you can go through! ;-D

Good for the soul, though, I suppose, and better than
not programming at all.

-- Terry

DISCLAIMER:
I have made every effort to ensure that there are no
objectively-verifiable statements in the above (any
seeming objective statements are hereby declared
bogus and void), making this entire communication
subjective, and most emphatically, IMHO. ;-D
Personally, I think the whole issue is aesthetic
and subjective, and I might like to make the assertion
that it is rigorously impossible to be otherwise. But
I'll leave that to the philosophers!

--
------------------------------------------------------
Terry Hancock
han...@anansispaceworks.com
Anansi Spaceworks
http://www.anansispaceworks.com
------------------------------------------------------


Roy Smith

unread,
May 1, 2002, 10:14:26 PM5/1/02
to
>> * Something that encourages a different style of thinking. [Lisp]

In that catagory, I would suggest PostScript. Most people just think of it
as a way to talk to printers. What they don't realize is that it's a real
programming language, with sophisticated flow control, data structures,
I/O, and memory management (in addition to the graphics and typography
support you would expect).

Now, granted, I wouldn't want to use it as a general purpose programming
language, but if your goal is to expose yourself to different ways of
thinking about programming, PostScript is certainly worth exploring. And,
it starts with a "P" :-)

bru...@tbye.com

unread,
May 1, 2002, 11:43:32 PM5/1/02
to
On Wed, 1 May 2002, Terry Hancock wrote:

> > My rule is simply: if there's no good reason to use !Python, use
> > Python. Now, what's a good reason not to use Python?
>
> I've got practical examples: I sometimes use Perl as a
> "super-sed". The original sed's REs are getting quite
> out of date, so it's kind of nice to use Perl's. Doing
> the same thing in Python is quite feasible, but will probably
> take about an hour longer to make work

An hour longer!?

>, because you have
> to get the import right

import re, sys # Time: 2 seconds

>, compile the regex

myRE = re.compile(RE_STR) # Time: 3 seconds

> and figure out
> how to get data in

data = sys.stdin.read() # Time: 2 seconds

or

while 1:
line = sys.stdin.readline()
if not line: break

# Time: 6 seconds

> and out of the program

print whatever # Time: 1 second

> All easy stuff,
> but extra lines of code, and if you're thumbfingered with
> the RE module it takes some time to get right.

The only meat left is to figure out the RE_STR, whose syntax will be
pretty close to Perl's. So, by your estimate I have about 59 minutes and
50 seconds not to figure out RE_STR, but simply figure out how it would be
different from the Perl version. Or, if I already know the Python re
syntax, I could just write the re, and I have a decent chance of finishing
in about the same time as it would take to write the Perl version.

My sample code may seem too contrived, but the
read-input-perform-sedlike-processing-and-dump-it problem is pretty
common, and I guarantee that it just doesn't take an hour longer than a
Perl version to wade through that "overhead". It really is on the order of
seconds, if that.

> If the project was going to take five minutes to write in
> Perl, then that's about 1200% overhead. Particularly
> nasty if the lifetime of use is another ten minutes.

A counter-example: I don't remember Perl that well, and a sed-like program
would take me 5 minutes to do in Python. Because my Perl skills are so out
of date, it'd take me TWO HOURS. That's 2400% overhead! <0.1 wink>

[snip]


> it (this is the Income Tax deadline in the US). I spent
> about 30 minutes and got the output to work using Perl.
> It was not particularly elegant, but only took about
> 10-20 lines of code.

[snip]


> The same thing would've taken me 3-4 hours in Python
> and about 40-50 lines

All of your examples point to the fact that you're more comfortable with
Perl than Python, and that's fine, but the exact opposite results can be
found if a person is more comfortable with Python than Perl; this has
nothing to do with whether or not the language is worth learning or using
though. There will be times when doing it in Perl is a little faster, and
vice versa, but claiming even a hundred percent gain in favor of Perl is
pretty FUD-like, IMO.

> It seems to me that (with considerable training overhead)
> Perl allows you to make these extremely short utterances
> of code which do very clever things, do them quickly,
> and with little development time (e.g. on the order of
> the single usage time, as above)

I find that the same is true with Python, with perhaps lower training
overhead. We routinely use it for one-off programs and utilities, and
literally *never* have one-offs requiring development that you'd measure
in hours. That's preposterous. If Perl works well for you on throw away
stuff, stick with it, but you're kidding yourself if you think that Python
has some inherent development overhead that is going to make more than a
few seconds difference.

Have fun,
-Dave


Aahz

unread,
May 1, 2002, 11:53:32 PM5/1/02
to
In article <roy-8C3C69.2...@news1.panix.com>,

Yeah, but I'd tell someone who wasn't particularly interested in
printers per se to learn Forth instead.

Aahz

unread,
May 2, 2002, 12:01:25 AM5/2/02
to
In article <mailman.102030198...@python.org>,

Terry Hancock <han...@anansispaceworks.com> wrote:
>
>I've got practical examples: I sometimes use Perl as a "super-sed".
>The original sed's REs are getting quite out of date, so it's kind of
>nice to use Perl's. Doing the same thing in Python is quite feasible,
>but will probably take about an hour longer to make work, because you
>have to get the import right, compile the regex and figure out how to
>get data in and out of the program. All easy stuff, but extra lines of
>code, and if you're thumbfingered with the RE module it takes some time
>to get right.
>
>If the project was going to take five minutes to write in Perl, then
>that's about 1200% overhead. Particularly nasty if the lifetime of use
>is another ten minutes.

My contention is that if something that takes you five minutes in Perl
takes you an hour in Python, you're doing something wrong. Here's a
grep.py that I wrote in ten minutes for the original version, plus
another ten minutes of fiddling to get the current version (I wrote it
for my OSCON tutorial):

from __future__ import generators
import sys, re

def grep(f, regex):
f = file(f)
regex = re.compile(regex)
for line in f:
if regex.search(line):
yield line

if __name__ == '__main__':
regex = re.compile(sys.argv[1])
if len(sys.argv) > 2:
flist = sys.argv[2:]
else:
flist = [sys.stdin]
for f in flist:
for line in grep(f, regex):
sys.stdout.write(line)

Now I've got a superstructure, and all I need is to add an appropriate
regex. Python's regexes are pretty damn similar to Perl's.

Tim Daneliuk

unread,
May 2, 2002, 1:40:06 AM5/2/02
to
Andrew McNamara wrote:
>
> >I have a lot of experience in ANSI C/C++, I want to learn a new
> >language and which it can help me in the work.
> >I just want to clear which(python or perl) is more comfort for me?
>

This question comes up with painful regularity on virtually every
language newsgroup in existence. The answers are almost always the
same. I think we need a meta-answer which address the question
once-and-for-all for any language extant or future. I thus humbly
submit the following as a candidate....


HOW TO PICK A PROGRAMMING LANGUAGE
----------------------------------
Tim Daneliuk
tun...@tundraware.com
May 1, 2002

Let L be the set of all programming languages ever conceived past, present,
and future. The meta-question, M, thus becomes:

Among all members of L, which is the "best" and thus, which should
I learn and use?

A variant of M, let's call it M', is:

Is L(x) "better" than L(y)?

Let P be the purpose for which you wish to learn a "best" language.

Let A be the answer to M or M' with condition P as a constraint. A is
thus the following set:


1) P = "I am interested in the design of languages and/or language theory."

Learn as many members of L as time permits. Do not pollute L with
your own ideas until you *really* understand what you are doing and
what has already been done. Then do so only if you are convinced you
can materially add to the state-of-the-art with original and useful
work. The world does not need another language just so you can prove
that you understand LR(1) grammars. Implement a subset of at least
one existing language yourself to see just how hard this is to do
well.


2) P = "My current language is too slow/big in its appointed task."

Most of the time, these problems have a lot more to do with poor
programming and algorithm/data structure design than they do the
language. *Really* get under the covers of your programming style and
design approach before you abandon the language you currently know
best. Read Bentley's "Programming Pearls." Learn to use a profiler.
Consider optimizations which merely replace the slow/big portions of the
code with something written in a naturally faster/smaller language.


3) P = "I have a specialty problem domain which is not well addressed
by a general purpose programming language."

Research what has already been done. You can often find close enough
matches to your problem within other problem domains to get something
useful done. If there really is nothing useful out there, strongly
consider using one of the extant scripting languages to build a
"little language" of your own which addresses your problem area. If
all else fails, ignore 1) above, and invent your own language, but
keep it as small and simple as possible, or you'll spend less time on
your chosen problem area and most of your time maintaining your new
language.


4) P = "I need to become/stay employable."

Survey common practice in your profession of choice and determine the
most common operating systems, GUIs, and languages already in use and
the probable evolution of these items in the next several years.
Based on this information, you should select one procedural language,
one object language, one scripting language, and, possibly, one
assembly language which will comprise your core skill set. In
selecting these, also consider the availability of supporting tools
like standard libraries, debuggers, language-sensitive editors,
profilers, and so on. If you have some choice of languages, always
prefer those that share a common link format and have compatible
inter-language calling APIs. If it comes down to a tie, pick the
older language because it will almost always have fewer bugs.


5) P = "I want to write 'portable' code."

Warning: Computer Science Heresy follows. I've already been burned
at the stake in this matter, so put your matches away.

Code 'portability' is overrated. Way more important is the
portability of your *programming skills*. Languages come and go
(well, they never really *go*, do they), but a good programmer
expresses themselves well in pretty much any language. This comes
with time, experience, reading other people's very good code and doing
it wrong over and over again. The most portable language in the world
can't help you if you don't understand algorithms, data structures,
object decomposition, and how to trade off between them. Writing
truly 'portable' code has as much to do with your understanding of the
underlying operating environments (hardware, OS, network, I/O, and
GUI) as it does with the language in question.

There are, of course, cases where portability *is* very important.
For example, if you are writing commercial software which must run on
lots of different platforms for your company to succeed. In that
case, first see if you can find cross-platform library support so you
don't have to do it all yourself.


6) P = "I want to make lots of money."

Quit programming. Become a rock star, actor, or corrupt politician.
The odds of getting rich in these fields, however slight, are probably
better than in programming.


7) P = "I've heard that OO is *the* way to do things, so I want the best
OO language."

OO is one way to crack a problem. It is not the only way. More importantly,
it is often not a *good* way. A solid OO language should be in your bag of
tricks, but it's not the only thing you will need.


8) P = "I've heard that AI is *the* way to do things, so I want the best
AI language."


See 7) above.


9) P = "I want to produce code faster."


Type faster. It doesn't matter what you type because if speed is your
goal you'll just become expert at writing buggy code, so why bother
with syntax and semantics at all? *Correct* code is always produced
by people who are thoughtful and deliberate about what they are doing.
Oh, and in the long run, they're almost always faster getting things
done too.


10) P = "I want the <gender/species> of choice to like me and be
impressed enough to go out with me."


See 6) above.


11) P = "The system I must use prescribes a vendor-defined language
and tool set. I want other choices."


See if there are Open Source or alternative vendor choices for that platform.
If not, master the languages/tools on that platform then broaden your horizons
as a matter of professional pride and employability. See 4) above.


12) P = "I'm very nerdy. All I like to do is code on as many different platforms
with as many different languages as I can. My Resume' is 14 pages long.
I have not been out of the house since 1982. Please help."


Get a life. Read some poetry, or better still, write some (without
using curly braces or semicolons). Learn a musical instrument that
does not require electricity in any form. Get a low-tech hobby like
gardening or sewing. You are an Addict - I feel your pain. As a
recovery strategy, consider volunteering your skills to a cause that's
worth your time and effort and which requires you to interact with
people who have absolutely no clue how a computer works. Try not to
be a jerk when the local minister does not grasp the elegance of your
finely tuned LaTeX macro for generating the Sunday Bulletin. Do
something good for your body and your spirit. I strongly recommend at
least one high-activity sport (channel surfing does not qualify) and
shooting semi-automatic handguns (at paper targets in a legal manner)
as excellent mind-clearing tools. Collect something other than
computer manuals.


13) P = "I want to be famous."

Rob a bank and get caught. OR Write a *ton* of really useful code and
then give it away.


14) P = "I'm bored, I need a new challenge."

If you already know more than 5 languages, consider joining the Navy Seals -
they are very busy at the moment and are always looking for an Adventurer
just like you. If you are over 19 and this is therefore impractical, get
married and raise children. You will never be bored.

Tim Daneliuk
"Bach, Sig-Sauer, Gibson Guitars, Python, & My Table Saw Made Me What I Am Today."

--
------------------------------------------------------------------------------
Tim Daneliuk
tun...@tundraware.com

Tim Daneliuk

unread,
May 2, 2002, 2:30:09 AM5/2/02
to
Tim Daneliuk wrote:
>
> Andrew McNamara wrote:
> >
> > >I have a lot of experience in ANSI C/C++, I want to learn a new
> > >language and which it can help me in the work.
> > >I just want to clear which(python or perl) is more comfort for me?
> >
>
> This question comes up with painful regularity on virtually every
> language newsgroup in existence. The answers are almost always the
> same. I think we need a meta-answer which address the question
> once-and-for-all for any language extant or future. I thus humbly
> submit the following as a candidate....
>
> HOW TO PICK A PROGRAMMING LANGUAGE

This now lives at:

http://www.tundraware.com/Technology/How-To-Pick-A-Programming-Language/

Alex Martelli

unread,
May 2, 2002, 5:16:55 AM5/2/02
to
bru...@tbye.com wrote:
...

>> and figure out how to get data in
>
> data = sys.stdin.read() # Time: 2 seconds
>
> or
>
> while 1:
> line = sys.stdin.readline()
> if not line: break
>
> # Time: 6 seconds

Actually, I think the "one obvious way to do it" is
(adding fileinput to the modules you import, and):

for line in fileinput.input():
whatever(line)

This gives you stdin if your script is called w/o
arguments, or else the files with whose names your program
is called -- basically like Perl's "while(<>)" (one
enhancement to fileinput I'd like is a switch to have
it implicitly call glob.glob on arguments that have
wildcards when running on Windows, because I do find
myself all the time wanting to use "python x.py *.foo"
indifferently on Windows or Unix-like systems -- but
that's another issue. I guess).


Alex

Alex Martelli

unread,
May 2, 2002, 5:58:24 AM5/2/02
to
François Pinard wrote:

> [Patrick W]
>
>> IMHO, the best choices for starters are:
>> * One of [C, C++]
>> * One of [Python, Perl, Python, Ruby, Python, Tcl, Python]
>> * Something that encourages a different style of thinking. [Lisp]
>> * Whatever else turns you on.
>
> Excellent advice and analysis, congratulations!
>
> I guess programmers should all get acquainted in their life with some
> non-procedural language. As some people are not inclined toward inference
> engines :-), one could aim languages like `SQL', non-procedural enough!

SQL is indeed a great choice, since it is both an entirely different
paradigm *AND* a language of huge practical and economic importance.

I'd just strongly suggest doing it RIGHT, i.e., studying SQL itself,
NOT some weird dialect (unfortunately many popular sort-of-SQL engines
do offer weird dialects -- e.g., no nested SELECT in MySQL...).

> `Lisp' (my preferred one is `Scheme', yet some people take offence when
> `Scheme' is presented as a `Lisp') encourages a different style of
> thinking, but still, it is an imperative, procedural language, like `C'
> and `Python'.

Right! For Functional Programming, I'd suggest Haskell, though others
will prefer some variants of ML or something more weird and exciting
yet (Erlang, Oz/Mozart, ...?).


Alex

Philip Swartzleonard

unread,
May 2, 2002, 7:18:31 AM5/2/02
to
Patrick W || Tue 30 Apr 2002 08:05:54p:

> rme...@gilia.nmsu.edu ("Bob Melson") writes:
>
>> If you're asked to build a house, you certainly don't confine
>> yourself to a single tool -- you use the tools appropriate to the
>> job you have to do; why should it be different with scripting
>> languages?
>
> Because the "right tool for the right job" approach is wrong in this
> context. It should apply to the choice of language _categories_, not
> languages _within_ a category. There are better things to do with time
> and mental energy than learn a dozen different ways of doing the same
> thing.
>
> If it took a minimum of six months to learn how to push two different
> brands of wheelbarrow, can you imagine an experienced builder saying
> to his apprentice: learn both?

<> [Various other arguments]

I've been thinking about this a bit today, and I think maybe a new take
on this metaphor would fit better. How about this, where we are
restricted to 'things that attach pieces of wood to each other':

Python, perl, ruby, lua, etc, are all various brands of glue. This kind
of tool was created later because of the more involved producer-side
work and knowledge required, but are now the easiest to get ahold of and
the easiest to start using. You don't need much education to stick two
pieces of wood together with them =).

C++ and Java are the other side of modernization in tools: highly
accurate plainer-jointers that produce beautiful and seemless interfaces
that fit together effortlessly-- but they take a large amount of put-out
to get set up and running properly and as they are huge, powerful
machines take a lot of skill to use _just right_ and create good works
with. You can still hurt yourself with these things.

Algol, pascal, ada, and all the languages that are a little safer than C
but of a similar type are different kinds of hammers and nails. You can
do good work with these things, but you can hit your thumb if you're
clumsy. (I've never used any of these btw...)

C itself is a framing nailer. The end results are about the same as a
hammer, but there is more power there, and you can shoot yourself in the
hand pretty easily. =)

Assembly is like a small ball-peen and finish nails, if used
appropriatly, or like a 100 pound mallet if not =).

Machine language is like trying to make a pocketwatch with a knife, some
rocks, and some string. McGuiverisms =).

The point is, there is a time for most of the types of tools. Only a
grand-master woodcrafter, or an old one who has lived through shifts in
technology and politics, would learn many different brands of a single
tool to a great depth. The rest of us just become proficient in one or
occasionaly two and muddle through when required to use a different
brand =).

Ah, gn'ight

--
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com

jep...@unpythonic.net

unread,
May 2, 2002, 8:28:21 AM5/2/02
to
On Thu, May 02, 2002 at 03:11:26PM +1200, Paul Foley wrote:

> On Wed, 1 May 2002 11:50:31 -0500, Jeff Epler wrote:
>
> >> Centuries ago, Nostradamus foresaw when "Mark McEahern" <mark...@mceahern.com> would write:
> >> > Could you give us a concrete example where the use of regular expressions in
> >> > Perl is superior to Python?
> >>
> > On Wed, May 01, 2002 at 01:02:07AM -0400, Christopher Browne wrote:
> >> Well, in Perl, they're "first class objects," as it were, requiring no
> >> extra references to functions to get them to function, as a base part
> >> of the language syntax.
>
> > I always thought that "first class" meant a type of object that can
> > be passed as an argument in a function.[1] In that sense, Python REs
>
> Yes, but it also needs to be a distinguished from other objects.

I don't understand how an object cannot be "first class" when it can be
treated indistinguishably from other kinds of things. Can you expand on
this claim? Surely you don't mean that only things that have to be
decorated to be treated as a value (like &sub or #'function) or require a
special syntax to define (like /..../ or def blah(x): ...) can be
first-class.

> > (as well as almost everything else in Python -- functions, instances,
> > bound methods, ...) are first-class, because you can write
>

> Python functions, instances, and methods are first class; REs aren't
> because there's no distinguished "regexp" object; they're either
> strings or instances.


>
> > def group(x): return r'\(' + x + r'\)
>

> This is a string.

And, a bit below (unless I screwed up the original post) I produce a
compiled regexp using re.compile. This is the object I'm claiming "is" a
regular expression and "is" first-class, since it can be "part of data
structures" (stored as an element of a sequence type, or in the attribute
of another object), "formed at runtime" (what I just did), "returned by
functions" (how I formed it) and "arguments to functions" (something the
next lines of code demonstrated).

> > The term first-class refers to the idea that values can be
>
> > * part of data structures,
> > * formed at run-time,
> > * arguments to functions, and
> > * returned by functions.
> > It's often said that functions are first-class in C (well, at least I've
> > heard it said)
>

> It's sometimes said (I've heard it, too), but it's wrong. What you're
> passing around are pointers, not functions.

I don't think that this is relevant. In fact, I bet it would be possible
for some C implementation to "inline" small functions in their "pointers".
For instance, a (perverse) architecture might have 128-bit function
pointers and 16-bit instruction words. The top bit of a pointer is
0 if it refers to memory, and 1 if the bits 112..0 refer to 7 16-bit
instruction words. Then, short functions like (hypot)
MUL %f0, %f0
MUL %f2, %f2
ADD %f0, %f2
SQRT %f0
NOP; NOP; NOP
could "fit" within the "function pointer". The natural calling sequence
MOV %f0, x
MOV %f2, y
CALL hypot
or
MOV %f0, x
MOV %f2, y
CALL %a0
would work, and it would be invisible to the programmer that the function
doesn't actually reside anywhere in particular in RAM (it could reside as
an "immediate" value in the current instruction stream, or it could reside
in the value of an address register.)

So, given that this interpretation will still allow the C language to
behave as it does, what justification (other than the syntax and
terminology of the language) makes it a "function pointer" and not a
"function value"?

Of course, you never pass any*thing* in a computer language -- you pass a
representation of the thing, or a value which corresponds to a
representation of a thing. It's just not constructive to think of
programming a computer in these terms. In the same way, in code like

r = re.compile(".")
f(r) # that line of code
I don't think "in that line of code, I'm passing a reference as an argument
to another reference treated almost as if it were a function (but of course
it's not, it's only bits)" I say "I'm passing the regular expression to a
function".

Jeff


Aahz

unread,
May 2, 2002, 10:29:10 AM5/2/02
to
In article <bu7A8.88593$vF6.2...@news2.tin.it>,

Alex Martelli <al...@aleax.it> wrote:
>
>Actually, I think the "one obvious way to do it" is
>(adding fileinput to the modules you import, and):
>
>for line in fileinput.input():
> whatever(line)
>
>This gives you stdin if your script is called w/o arguments, or else
>the files with whose names your program is called -- basically like
>Perl's "while(<>)" (one enhancement to fileinput I'd like is a switch
>to have it implicitly call glob.glob on arguments that have wildcards
>when running on Windows, because I do find myself all the time wanting
>to use "python x.py *.foo" indifferently on Windows or Unix-like
>systems -- but that's another issue. I guess).

What I'd like is an argument to specify how many command-line args to
skip over, say if you're writing something like grep.py.

Alex Martelli

unread,
May 2, 2002, 11:13:09 AM5/2/02
to
Aahz wrote:
...

> What I'd like is an argument to specify how many command-line args to
> skip over, say if you're writing something like grep.py.

import fileinput, sys, re
there = re.compile(sys.argv.pop(1))
for line in fileinput.input():
if there.search(line): print line,

Normally, you'd also use options-processing (not to mention error
checking), but even then you get a separate list of real, non-option
args that you can slice or pop things off before passing it on to
fileinput.input. I'm just lazy in not wanting to map glob.glob over
said list and flatten the results iff I'm on a platform with a
nonglobbingbydefault shell... I'd rather have fileinput.input optionally
do it for me iff the platform needs it:-). Perhaps unwise...


Alex

Steve Holden

unread,
May 2, 2002, 11:42:29 AM5/2/02
to
"Patrick W" <quite...@yahoo.com.au> wrote ...
[...]

>
> import IMHO and sprinkle it liberally throughout.
>
> A programmer ought to know at least four languages in depth. If those
> four languages are well chosen, they can last a lifetime. If they lack
> certain features that come pre-packaged elsewhere, it's far better to
> acquire the _concepts_ and _techniques_ implicit in them, and
> implement them in your chosen language(s), as opposed to madly
> accumulating new notations simply because they possess a convenient
> feature or two.
>
So, what you seem to be saying is that I should have stuck with Algol 60,
PLAN, PL/1 and IBM 1130 assembly language?

> I think this popular notion of "right tools for the right job" is
> actually very harmful, both to individuals and to the science/industry
> as a whole. To stick with the tradesman metaphor for a moment, I think
> it creates a culture in which programmers are encouraged to become
> "jack of all trades, master of none." Resumes may be stuffed full of
> impressive sounding acronyms, but programmers actually don't know as
> much as they once did. It's not because we're stupid (although the
> barrier to entry is considerably lower these days); it's partly a
> result of having too many alternative implementation details to
> learn. When depth is sacrified for breadth, beyond a certain point, it
> becomes a very bad thing.
>

There is something in what you say, but I would prefer to think that one
moves to a new language precisely because it does offer better wasy of using
fundamentally new paradigms. If someone wants to use object-oriented
techniques they would be hard-put to graft them onto (say) Algol 60.

> To make sensible choices up front, and to focus on a few languages and
> topics to the exclusion of many others is the only way to go. That's
> why I reject this "learn them both" approach, unless the languages are
> different enough in purpose and style and philosophy to make them both
> worthwhile and complementary.
>

Another problem, of course, is that often times the learner has no choice,
or is badly guided, and then has to change anyway. Plus, of course, changes
of job can mandate changes of language.

> So, choice is necessary, but what to choose?
>
> IMHO, the best choices for starters are:
>
> * One of [C, C++] for maximum efficiency, minimal overhead and an
> understanding of the low-level foundations of higher level
> facilities.
>

I think it's dangerous to equate these two languages, as despite C++ being a
superset of C it contains many things, and implements many concepts, which C
does not. I regard them as being fundamentally different: C is a sort of
high-level assembly language, whereas C++ is a Swiss army knife.

> * One of [Python, Perl, Python, Ruby, Python, Tcl, Python] for general
> purpose programming and scripting. For my money, Python is the clear
> winner in this category. It's great for everything from text
> processing and os scripting through to graphics, multimedia, comms,
> database programming, web development, etc. It's just as much fun
> for skilled hackers as it is for beginners.
>

Now you're talking.

> * Something that encourages a different style of thinking. My own
> favourite (for this purpose) is Lisp. I feel that Lisp is powerful
> enough to handle anything I'll ever throw at it, and it's flexible
> enough to incorporate any new programming paradigms that computer
> scientists are brilliant (or crazy, or foolish) enough to think up.
>
> * Whatever else turns you on.
>

[...]


> Absolutely. Then extend it with concepts and techniques from many
> other sources. There's far more value in that than in learning a new
> notation every few months (provided the initial choices are good
> ones).

Not all languages extend easily. Even Visual Basic, as sundry a hodge-podge
of accumulated features and syntax as could be desired, has had to be
mangled heavily to bring it into the .NET world. Most of the changes are
justifiable rationalisations.

The really interesting thing is the lack of noise from the VB community
about that, while the poor Python development team have to suffer howls of
anguish just to get True and False into the language ;-)

regards
Steve
--
Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/

Aahz

unread,
May 2, 2002, 12:45:54 PM5/2/02
to
In article <6bdA8.54737$Au5....@atlpnn01.usenetserver.com>,

Steve Holden <sho...@holdenweb.com> wrote:
>
>The really interesting thing is the lack of noise from the VB community
>about that, while the poor Python development team have to suffer howls of
>anguish just to get True and False into the language ;-)

Simple answer: baaa! baaa!

Now, what would you rather be, sheep or wolf?

Gerhard Häring

unread,
May 2, 2002, 12:18:08 PM5/2/02
to
* Steve Holden <sho...@holdenweb.com> [2002-05-02 11:42 -0400]:
> [...]
> Not all languages extend easily. Even Visual Basic, as sundry a hodge-podge
> of accumulated features and syntax as could be desired, has had to be
> mangled heavily to bring it into the .NET world. Most of the changes are
> justifiable rationalisations.
>
> The really interesting thing is the lack of noise from the VB community
> about that, while the poor Python development team have to suffer howls of
> anguish just to get True and False into the language ;-)

That's because Visual Basic 6 isn't really a language. I view it as the
de-fact standard test container for COM components, and as an IDE for
assembling COM components that you buy from third parties. Using it as a
language to write more than the most simple glue code can hurt your
brain, seriously. Only some examples:

- ridiculous error checking (On Error Goto); no exceptions
- no usable data structures in the standard libraries (even the
Dictionary object is too limited; try to use a custom Class as a key,
for example)
- no multithreading

I'm someone who got burned trying to actually write code in this
"language", while working at a mostly MS/Oracle shop. I hope I'll never
have to touch VB <= 6 again.

Gerhard
--
This sig powered by Python!
Außentemperatur in München: 15.5 °C Wind: 4.3 m/s


Christopher Browne

unread,
May 2, 2002, 2:36:14 PM5/2/02
to
Centuries ago, Nostradamus foresaw when "Steve Holden" <sho...@holdenweb.com> would write:
> "Patrick W" <quite...@yahoo.com.au> wrote ...
> [...]
>>
>> import IMHO and sprinkle it liberally throughout.
>>
>> A programmer ought to know at least four languages in depth. If those
>> four languages are well chosen, they can last a lifetime. If they lack
>> certain features that come pre-packaged elsewhere, it's far better to
>> acquire the _concepts_ and _techniques_ implicit in them, and
>> implement them in your chosen language(s), as opposed to madly
>> accumulating new notations simply because they possess a convenient
>> feature or two.

> So, what you seem to be saying is that I should have stuck with
> Algol 60, PLAN, PL/1 and IBM 1130 assembly language?

In a sense, yes.

The regular "sheep flight" where the sheep "nest" in one language for
a couple of years, and head on to the next as soon as it emerges as
"hot" has taken people assortedly through:

-> BASIC
-> FORTRAN, PL/1, COBOL
-> Turbo Pascal
-> C, C++, Java
-> Ada, for some
-> Perl, leaping to Python or Ruby or PHP
-> xBase languages and Clipper
-> "4GLs" like Natural, Focus, ABAP/4

And the typical result I keep seeing isthat you get people writing
crummy looking COBOL-like code in whatever language they come to.

Perl gets bashed as being "unreadable;" my opinion is that while this
_is_ a commonplace result, it comes not because Perl is inherently
horrible or unreadable, but rather because it is a place where two
"herds" have come together:

-> On the one hand, there are some clever members of the herd that
have great fun in using oddball idioms to build over-clever code
that is intentionally unreadable.

-> On the other hand, most of the "stampede" is made up of people
that used to write bad COBOL, and have leaped over to Perl with
the result that they write bad COBOL in Perl, achieving a sort
of "worst of all possible worlds" (one that Pangloss wouldn't
like).

Those two groups are far more visible than those that have the ability
and intent to write readable code.

I think we'd be better off if there hadn't been such a stampede to
create slightly distinct new languages. Actually, that's not quite
right. The problem isn't in the creators. The problem is in the
"morons" that stampede to whatever is new.

I think it's fair to say that crummy Perl code is uglier and less
readable than most anything else, and that Python has some language
features that at least marginally discourage the creation of such
greatly despicable code.

Nonetheless, any language to which "morons" stampede will get
inundated with ham-handed morons. This has the natural result that
there will be a bunch of ugly, broken, unreadable code (even in
Python).

At some point, someone will notice this, and say "Language FOO
supports writing a lot of horrible code; I'll make something better!"
at which point something _marginally_ better in _some_ way is
developed, and if it becomes a bit popular, the morons will leap over
to it.

It's pretty ironic to point to Greenspun's principles of programming:

"Any sufficiently complicated C or Fortran program contains an ad
hoc informally-specified bug-ridden slow implementation of half of
Common Lisp." -- Philip Greenspun

"Every sufficiently unreadable programming language contains a
reimplementation of APL and/or INTERCAL." -- Greenspun's Eleventh
Rule of Programming

There was a pretty clear progression of improvements between Pascal,
Modula, Modula-2, and Modula-3; it is much less obvious that Ada is
_fundamentally_ better than, say, M3.

It's probably fair to call C++ the PL/1 of the 1990s; it is NOT
evident that it is clearly a vastly superior language to PL/1, despite
being a whole lot newer. It's pretty funny when people point to C++
and describe it as "Simula--". And it's also instructive that
aficionados of Algol point to it being better than most of its
successors. That seems very likely to be true.

I think what we're mostly seeing, in the language "popularity wars,"
is the principle that
Foo is newer, and therefore better
absent of actual evidence to support that.

People are still adding features to OSes that can be traced back to
Multics, available in the 1960s.

I expect that someone could make a great career as a "language
designer" by simply coming out with a new language every few years
that adds in a feature or two that was in Algol that none of the other
language designers has been literate enough to have bothered noticing.

There's _some_ hyperbole in that expectation, only some.

Just look at Ruby for a bit of an example. One of the matters of
"significant excitement" in it is that it brings back "mixins" as an
object model. That's something that dates back to the early days of
Common Lisp and FLAVORS.

I would bet almost any money that someone could similarly make a
"career" of creating new languages simply by picking features out of
CLOS and using them as the basis for a "new language."
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.cbbrowne.com/info/lsf.html
It is in the tranquillity of decomposition that I remember the long
confused emotion which was my life.

Jeff Shannon

unread,
May 2, 2002, 3:21:42 PM5/2/02
to
In article <mailman.102030198...@python.org>,
han...@anansispaceworks.com says...

> A slightly less trivial example was a problem in which my
> partner had recorded a bunch of business transactions in
> a comma-separated list in what turned out to be the wrong
> order. She wanted to flip everything around and compute
> sums over it.

Note that (if I understand your description properly) this would
take approx. 3-5 minutes to do using Excel or another decent
spreadsheet application -- import the CSV, move columns/rows
around, save as CSV again. And compute your sums while you're at
it.

Once again, the right tools for the job... ;)

--

Jeff Shannon
Technician/Programmer
Credit International

John J. Lee

unread,
May 2, 2002, 4:48:59 PM5/2/02
to
On Wed, 1 May 2002, Alex Martelli wrote:
[...]
> It may or may not be worth superficially learning both Perl and Python
> before going in depth into either (if it is, then I think Ruby should also
> be in the mix). But "variable markers" are still quite a deep difference.

What differences did you have in mind, between Python and Ruby, that are
really significant? I've always lazily assumed there are none (based on
a few minutes scanning of a web page or two).


John

Aahz

unread,
May 2, 2002, 5:09:11 PM5/2/02
to
In article <9IcA8.90097$vF6.2...@news2.tin.it>,
Alex Martelli <al...@aleax.it> wrote:

>Aahz wrote:
>>
>> What I'd like is an argument to specify how many command-line args to
>> skip over, say if you're writing something like grep.py.
>
>import fileinput, sys, re
>there = re.compile(sys.argv.pop(1))
>for line in fileinput.input():
> if there.search(line): print line,

Thanks! I don't really like "print line,", because it adds an extra
space that wasn't there before, so I prefer sys.stdout.write(). It's a
matter of taste, though.

Alex Martelli

unread,
May 2, 2002, 5:19:29 PM5/2/02
to
John J. Lee wrote:

Ruby's built-in classes are modifiable -- so you can instantly change
the behavior of all existing strings, for example. Python, while highly
dynamic, draws the line quite a bit short of that.

Ruby's approach to iterators is close to Smalltalk's - you pass an
unnamed code block as an argument to a method. In Python,
iterators 'extract' values linearly, and the code block that handles
one value at a time is typically placed as the body of a for statement.
Sort of inside-out from each other, and not exactly overlapping in
terms of what each approach makes it easy to do, though close.

Ruby's closer to Perl in many small details, although, as I understand,
some are deprecated (in the original sense, i.e., "they're there but we're
sorry they are"), such as the ability to call functions without parentheses
in certain cases, or special global variables with strange (non alphameric)
names. I guess these shouldn't count as "deep".


Alex

Alex Martelli

unread,
May 2, 2002, 6:14:08 PM5/2/02
to
Aahz wrote:

>>for line in fileinput.input():
>> if there.search(line): print line,
>
> Thanks! I don't really like "print line,", because it adds an extra
> space that wasn't there before,

Where do you think it adds that space...?

[alex@lancelot indomo]$ cat -E prova
uno due tre$
sei due cinque$
palik palok$
tre due uno$
[alex@lancelot indomo]$ python mygrep.py due prova | cat -E
uno due tre$
sei due cinque$
tre due uno$
[alex@lancelot indomo]$

> so I prefer sys.stdout.write(). It's a matter of taste, though.

I like sys.stdout.write, too, but I'm still perplexed by the "adds an
extra space that wasn't there before" assertion. You *are*
familiar with print's "softspace" mechanism, surely? Is there
some peculiar corner case that I'm failing to think of...?


Alex


Aahz

unread,
May 2, 2002, 7:46:43 PM5/2/02
to
In article <QSiA8.40950$8D3.1...@news1.tin.it>,

Alex Martelli <al...@aleax.it> wrote:
>Aahz wrote:
>>Alex:

>>>
>>>for line in fileinput.input():
>>> if there.search(line): print line,
>>
>> Thanks! I don't really like "print line,", because it adds an extra
>> space that wasn't there before,
>
>Where do you think it adds that space...?
>
>[alex@lancelot indomo]$ cat -E prova
>uno due tre$
>sei due cinque$
>palik palok$
>tre due uno$
>[alex@lancelot indomo]$ python mygrep.py due prova | cat -E
>uno due tre$
>sei due cinque$
>tre due uno$

<blink> Learn something new every frickin' day. I was not familiar with
this extra cute magic behavior of "print ," at the end of a line. I
guess I like it, but I'm still a bit suspicious for no reason -- I think
I got confused way back when I was first learning Python and got the
double-spaced output of regular print, assuming that a space still got
stuck at the end of a line with "print ,", and never actually trying it.

Let this be a lesson to you newbies. ;-) (But I have no clue what
lesson it should be...)

Paul Rubin

unread,
May 2, 2002, 8:34:57 PM5/2/02
to
aa...@pythoncraft.com (Aahz) writes:
> Let this be a lesson to you newbies. ;-) (But I have no clue what
> lesson it should be...)

It means print is even more complicated than I thought. I'm sorry but
I still consider the extra spaces from the print statement to be a
Python wart. Perl prints exactly what you tell it to, and I believe
that's the correct behavior. "Explicit is better than implicit".

Patrick W

unread,
May 2, 2002, 9:17:26 PM5/2/02
to
"Steve Holden" <sho...@holdenweb.com> writes:

> "Patrick W" <quite...@yahoo.com.au> wrote ...
> [...]
> >

> So, what you seem to be saying is that I should have stuck with Algol 60,
> PLAN, PL/1 and IBM 1130 assembly language?

Yeah, maybe "a lifetime" was a bit of an exaggeration.

> There is something in what you say, but I would prefer to think that one
> moves to a new language precisely because it does offer better wasy of using
> fundamentally new paradigms. If someone wants to use object-oriented
> techniques they would be hard-put to graft them onto (say) Algol 60.

This argument works both ways depending on which language you choose
as an example. As you say, it would be hard to program in a "modern"
OOP style in Algol 60, but it's done all the time in the Lisp family,
which is older than Algol. In fact it's done in ways that _still_
haven't found their way into the mainstream (but probably will one
day, packaged up and sold as something "innovative", or even
"revolutionary"). Obviously, new languages and dialects are sometimes
necessary to support new paradigms, but I argue that it's _necessary_
less often than it's _done_.

I'm not trying to be awkward though. I take your point. How about we
reduce "a lifetime" to "15 years or so" (without wishing to send
anyone to an early grave?) ;-)

> Another problem, of course, is that often times the learner has no choice,
> or is badly guided, and then has to change anyway. Plus, of course, changes
> of job can mandate changes of language.

Yeah, that's why I left slot (4) vacant. Sub "whatever else turns you
on" for "whatever pays the bills" if you must.

> [C, C++] I think it's dangerous to equate these two languages, as


> despite C++ being a superset of C it contains many things, and
> implements many concepts, which C does not. I regard them as being
> fundamentally different: C is a sort of high-level assembly
> language, whereas C++ is a Swiss army knife.

No, you misunderstand me. I wasn't equating them. I listed them as
examples of languages that permit low-level, minimal-overhead, systems
level programming. The fact that C++ crosses several categories
doesn't exclude it from this one.

> Not all languages extend easily. [...]

Aye, there's the rub.

As a general rule though, I still think it's better to choose
carefully and go for reasonable combination of depth and breadth. The
main guts of my argument is that it leaves more time for learning
important concepts. If the need arises to change languages, those
concepts will still be around.


Andrew McNamara

unread,
May 2, 2002, 9:40:03 PM5/2/02
to
>Andrew McNamara wrote:
>>
>> >I have a lot of experience in ANSI C/C++, I want to learn a new
>> >language and which it can help me in the work.
>> >I just want to clear which(python or perl) is more comfort for me?
>
>This question comes up with painful regularity on virtually every
>language newsgroup in existence. The answers are almost always the
[...]

Excuse me Tim, I didn't write the message you replied to. Please take more
care with your attributions, or turn them off if you can't get them right.

--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/


Peter da Silva

unread,
May 2, 2002, 10:18:30 PM5/2/02
to
In article <m3bsbyb...@chvatal.cbbrowne.com>,

Christopher Browne <cbbr...@acm.org> wrote:
> It's probably fair to call C++ the PL/1 of the 1990s;

That is HORRIBLY unfair to PL/I.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

Tim Daneliuk

unread,
May 2, 2002, 10:50:03 PM5/2/02
to

Noted, very sorry... slinking away in embarassment...

Christopher Browne

unread,
May 2, 2002, 11:09:03 PM5/2/02
to
Centuries ago, Nostradamus foresaw when pe...@abbnm.com (Peter da Silva) would write:
> In article <m3bsbyb...@chvatal.cbbrowne.com>,
> Christopher Browne <cbbr...@acm.org> wrote:
>> It's probably fair to call C++ the PL/1 of the 1990s;
>
> That is HORRIBLY unfair to PL/I.

Why not?

-> Both are complex languages;
-> Both had periods of considerable popularity;
-> Both were billed as the preferred replacements for practically all
of their predecessors.

PL/1 was certainly pegged as the successor to both COBOL and FORTRAN;
in practice, it really only succeeded COBOL, and that only in part.

C++ has had similar "billings" with not dissimilar success.

None of that points to any of the _technical_ qualities of the
languages, but I wasn't pointing at all at technicalities in this
context...
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www.cbbrowne.com/info/languages.html
"Laugh-a while you can, Monkey Boy." -- Dr. Lizardo - Buckaroo Banzai

Alex Martelli

unread,
May 3, 2002, 3:10:27 AM5/3/02
to
Paul Rubin wrote:

I find Python's print convenient for debugging purposes, and that's
about all. No matter how refined the theoretical possibilities, some
of us dinosaurs, at times, feel most comfortable rapidly sticking print
statements at strategic points in the code to follow the control flow
and data values, then commenting some of them out again, and so
on. For this purpose, print's "convenience" features are just fine --
they save me a fraction of a second each time wrt explicitly using
blanks, str calls, etc, or a formatstring. I've seen some beginners
appreciate it similarly -- it's simplest to use for beginners' typically
simple requirements (you could see this as a subcase of 'debugging',
in that a beginner's often debugging his or her own knowlegde of
the language;-).

Beyond such uses, for which it's fine, print can indeed be considered
a minor wart. It 'should' surely not be a statement, but a function
(probably; perhaps a fileobject method, but i'm inclined to function by
analogy with many other builtins -- the fileobject's responsibilities are
embodied in the write method, just as other arguments are accessed
through their stringification, only).

Maybe (in the abstract -- backwards compatibility surely makes the
change unfeasible now) print should be indeed a statement, but one
much like assert -- to be ignored when Python is run with -O. After
all, one doesn't use -O when debugging, or learning the language:-).
Being a statement would be justified by the ignore-unless-debugging
feature (a function would have its arguments evaluated anyway, thus
paying substantial runtime price uselessly). Just musing...


Alex

Alex Martelli

unread,
May 3, 2002, 3:25:07 AM5/3/02
to
Aahz wrote:
...

> <blink> Learn something new every frickin' day. I was not familiar with
> this extra cute magic behavior of "print ," at the end of a line. I

It's called the "softspace" behavior, because that's the name of the
attribute of the file or file-like object that print uses to control it.
It's best viewed by having a filelike object that traces setting and
getting of softspace, and printing to it -- e.g.:

class Flo(object):
def __init__(self):
self._softspace = 0
def setSS(self, v):
print "sSS %s->%s"%(self._softspace,v)
self._softspace = v
def getSS(self):
print "gSS ->%s"%self._softspace
return self._softspace
softspace=property(getSS,setSS)
def write(self, buf):
print "wri %r"%buf

flo = Flo()
print >> flo, 'One','Two'
print
print >> flo, 'With a nl\n',
print
print >> flo, 'without',
print
print >> flo, 'finis'

The trace will then be:

gSS ->0
sSS 0->1
wri 'One'
gSS ->1
sSS 1->1
wri ' '
wri 'Two'
wri '\n'
gSS ->1
sSS 1->0

gSS ->0
sSS 0->1
wri 'With a nl\n'
gSS ->1
sSS 1->0

gSS ->0
sSS 0->1
wri 'without'

gSS ->1
sSS 1->1
wri ' '
wri 'finis'
wri '\n'
gSS ->1
sSS 1->0


I think this is pretty instructive. You'll see the extra ' ' is written
separately, conditionally on the previous value of softspace; SS
itself is set to 1 or 0 depending on whether a \n was last emitted,
etc. This bit of extra state is kept per-file in the most natural
way, i.e. through a fileobject attribute (if you write your own
fileobjects, make sure their softspace attribute can be set and
read -- care is only needed if you have __slots__ or for a C-coded
extension).

All in all, a neat hack, even though I fully understand not wanting
to rely on such stuff for "production code", when sys.stdout.write
is far simpler and easier to control. So, I'll agree that my use of
the "print someline," idiom/trick was inferior, in as much as that
short program WAS meant to be an example of "production code"!
'print' is often NOT "the simplest thing that can possibly work"...


Alex

Tom Verbeure

unread,
May 3, 2002, 7:36:57 AM5/3/02
to
Lots of answers already. This is what I experienced at work:

I have been hacking Perl for years, was mostly happy with the outcome
of my programs, but never satisfied with the way it looked.
Also, I have tried to push my collegues (all electrical engineers, not
software engineers) into scripting commond operations and writing
larger programs for complex repetitive stuff. I was never able to get
them 'that' far.

The last 3 months I have been pushing Python on them, raving about the
cleanliness of the code and the combination of simplicity and power
and showing them actual examples. Suddenly, my 'Learning Python' and
'Python Programming' books are in high demand and everbody start
writing more and more complex programs. I love it! :-)

I still use Perl for very quick hacks (script of max. 5 or 6 lines),
but other than that it's all Python. Learn Python first...

Tom

xiaots...@hotmail.com (David) wrote in message news:<df30afd4.02042...@posting.google.com>...

Jason Voegele

unread,
May 3, 2002, 10:42:18 AM5/3/02
to
Chiming in from the Ruby perspective...

Alex Martelli <al...@aleax.it> wrote in message news:<B3iA8.91514$vF6.2...@news2.tin.it>...


> John J. Lee wrote:
>
> > What differences did you have in mind, between Python and Ruby, that are
> > really significant? I've always lazily assumed there are none (based on
> > a few minutes scanning of a web page or two).

[snip some good points about Ruby]

> Ruby's closer to Perl in many small details, although, as I understand,
> some are deprecated (in the original sense, i.e., "they're there but we're
> sorry they are"), such as the ability to call functions without parentheses
> in certain cases, or special global variables with strange (non alphameric)
> names. I guess these shouldn't count as "deep".

You are correct concerning the special global variables ($_ and
friends). Only long-time Perl hackers are very fond of them. Even
matz has said that if he re-designed the language from scratch he
would probably leave them out.

On the other hand, the ability to call functions without parentheses
is not so clear-cut. Some believe that it leads to less readable
code. Others (such as myself) view it as essential for supporting the
Uniform Access Principle. Usually I'll leave the parentheses off of a
method call if it takes no arguments, which allows me to switch
between using a variable and using a method more easily. I also find
it easier to read in such cases. I find empty parentheses() as you
find in C++, Java, and Python rather ugly (a "call" statement in
disguise, as it were), although at least in Python and C++ they are
actually an overridable operator, whereas in Java they are just
gratuitous syntax.

In addition, I'll leave the parentheses off of function calls that are
conceptually similar to keywords. For example, Ruby's "raise" method
(which raises an exception), or an "assert" method from a testing
framework, or attr_accessor and friends.

Just my $.02

--
Jason Voegele
"We believe that we invent symbols. The truth is that they invent us."
-- Gene Wolfe, The Shadow of the Torturer

Patrick W

unread,
May 3, 2002, 10:54:01 AM5/3/02
to
ja...@jvoegele.com (Jason Voegele) writes:

> [...]


> On the other hand, the ability to call functions without parentheses
> is not so clear-cut. Some believe that it leads to less readable
> code. Others (such as myself) view it as essential for supporting the
> Uniform Access Principle. Usually I'll leave the parentheses off of a
> method call if it takes no arguments, which allows me to switch
> between using a variable and using a method more easily. I also find
> it easier to read in such cases. I find empty parentheses() as you
> find in C++, Java, and Python rather ugly (a "call" statement in
> disguise, as it were), although at least in Python and C++ they are
> actually an overridable operator, whereas in Java they are just
> gratuitous syntax.

FYI, recent versions of Python also support the "Uniform Access
Principle" via "properties" (like Delphi and, now, C#). Not sure which
version of Python introduced this, but it's a nifty little
enhancement, IMO.

Mark McEahern

unread,
May 3, 2002, 11:05:02 AM5/3/02
to
[Patrick W]

> FYI, recent versions of Python also support the "Uniform Access
> Principle" via "properties" (like Delphi and, now, C#). Not sure which
> version of Python introduced this, but it's a nifty little
> enhancement, IMO.

I think property is new with 2.2.

// m


Andrew Dalke

unread,
May 3, 2002, 11:12:16 AM5/3/02
to
Patrick W:

>FYI, recent versions of Python also support the "Uniform Access
>Principle" via "properties" (like Delphi and, now, C#). Not sure which
>version of Python introduced this, but it's a nifty little
>enhancement, IMO.

Or to fogies like me, __getattr__ / __setattr__ / __delattr__ have
been around for a long time and solve that task.

Andrew
da...@dalkescintific.com

Alex Martelli

unread,
May 3, 2002, 12:02:24 PM5/3/02
to
Jason Voegele wrote:
...

> On the other hand, the ability to call functions without parentheses
> is not so clear-cut. Some believe that it leads to less readable
> code. Others (such as myself) view it as essential for supporting the
> Uniform Access Principle. Usually I'll leave the parentheses off of a

"Properties" do UAP better, and meanwhile you get uniformity at ANOTHER
level: all methods are also attributes and you can deal with them as
you deal with other attributes.

In other words, in a language that lets you access object attributes
directly (except when properties are interposed, etc), parenthesis-less
function calls may be seen as _damaging_ uniformity:
x = y.z
if y.z is a 'real' attribute, bind its value to z; but if y.z is a
callable attribute (method), then DON'T bind the attribute to z, but
rather implicitly and invisibly CALL it and bind the RESULT to x.

You may not like the uniformity between callable and non-callable
attributes, but personally I find it one of Python's strengths.

As an analogy, consider assignment in VB6:

x = y

(x and/or y might be composite names, and you may optionally use a
LET verb before x, though nobody ever did:-).

In VB6, this means: if x is a normal thing, assign to x; but if x
is a special object, then assign to the *default property* of x
instead, i.e., actually do (e.g.) x.value = y -- and similarly for
y, it's used directly if "a normal thing", but if "a special
object", then the "default property" is used instead. So depending
on the nature of x and y this might actually be doing (assuming
the default property is named 'value', popular but not mandatory):
x = y
x.value = y
x = y.value
x.value = y.value
When you wanted to REALLY TRULY do x = y for special objects, you
then had to code explicitly:
SET x = y
(which would then give error unless x and y ARE special objects,
but that's another wart yet:-).

I've long considered it one of the worst warts of VB, and surely
one which most confused VB beginners (even ones with some good
experience in other languages) -- whenever called upon to help
find a bug I always looked first for missing SET verbs and often
found one.

Apparently Microsoft agreed, since in the move to VB7 (aka VB.NET)
they took the opportunity to make lots of incompatible changes to
the language -- including removing this misguided application of the
ideas of polymorphism and uniformity.


Having to know whether x.y is callable or not before I'm able to
store [a reference to] the attribute itself somewhere, IMHO, makes
callable attributes less than first class citizens and thus in
a way breaks uniformity.


In my experience, 9 times out of 10 I can afford to just let client
code get at an attribute -- and 10% of the time I want this to be
("trigger", if you will) a function call instead. It's higher for
_setting_ of attributes -- maybe as high as 30%. Still, in many
cases I don't need functions to be called. This is borne out by a
non-systematic observation of Java getThis, setThat methods -- it
seems to me that a vast majority of cases sees these methods as
boilerplate just copying some piece of data in or out, no more.

Old Python's ("classic object model") lets you "build" properties
out of special methods __getattr__ and __setattr__ -- not too bad,
though not maximally elegant (particularly because if you define
__setattr__ you must then bypass it carefully for *internal* cases
of access -- __getattr__ has no such problems). 2.2's "new object
model" adds Properties as (IMHO) one of its most significant
features (head to head with subclassing builtin types -- which,
admittedly, Ruby always had:-). For those 10% or 30% or whatever
of cases where I need methodcalls triggered upon attribute get
and/or set, I THEN write accessor methods (I found it most easy
and useful to name them getThis, setThat -- Java conventions) and
group them into a property with an assignment in class-scope
prop = property(getProp, setProp)

Now, and now only, will accessing x.prop or setting x.prop=23
call x.getProp and x.setProp as appropriate. __getattr__ is now
needed only for rather special uses (works great for 'blind
aggregation/delegation' for example -- since methods are gotten
just like any other attribute).


> method call if it takes no arguments, which allows me to switch
> between using a variable and using a method more easily. I also find
> it easier to read in such cases. I find empty parentheses() as you
> find in C++, Java, and Python rather ugly (a "call" statement in
> disguise, as it were), although at least in Python and C++ they are
> actually an overridable operator, whereas in Java they are just
> gratuitous syntax.

Yes, you can't take a reference to a method in Java (while you can
in Python, and also, sort of, in C++, though it's a "method
pointer" there, and rather unwieldy). Calling is indeed an OPERATOR,
while the lack of operator means "a reference to this thingy over
here". Now THAT is uniformity: naming something always gets a
reference to that thing -- if and when you want to DO something
with that reference, you express that "something". Properties let
you control the 'dot-operator' selectively and with very fine grain.


> In addition, I'll leave the parentheses off of function calls that are
> conceptually similar to keywords. For example, Ruby's "raise" method
> (which raises an exception), or an "assert" method from a testing
> framework, or attr_accessor and friends.

Given that raise and assert are statements in Python (Ruby is more
flexible by having them as methods, though Python's design choice
has its own little pluses too -- interesting tradeoffs), I can hardly
criticize you for "wanting" them to be in Ruby too:-).


Actually, it's when a callable HAS arguments that it may be least
disruptive to allow it to be called without parentheses, just by
"juxtaposition" to its arguments. I do admit I love Haskell's
way of expressing "f a b c", so clean -- no noisy parentheses nor
commas for the typical case. Of course, it DOES require the
"implicit currying" concept, so that e.g. f a may return a function
that then takes b and returns a function that ... -- delightful,
but perhaps not all that applicable unless the compiler has some
strong information about what callable takes what arguments:-).

For a compiler lacking such knowledge, I opine that unformly
mandatory parentheses as "call-operator" is probably simplest
and thus preferable -- though I sympathize with the drive to
avoid "useless pixels on the screen" (one habit I truly detest
is putting wholly unneeded parentheses around the value[s] in
a return statement -- some do that in C, too -- or, in Python,
around the condition in an if or while... *eeech*...).

One day I'd really love to co-author a *balanced* comparison
of Python's and Ruby's pluses and minuses -- "co-author" 'cause
I'd need to find a partner in crime who admires Python but
still prefers Ruby, just as I admire Ruby but still prefer
Python -- and one "into" Ruby's triviae and minutiae as well
as overall philosophy as much as I'm "into" Python's. Oh well, one day...


Alex

François Pinard

unread,
May 3, 2002, 11:35:20 AM5/3/02
to
[Christopher Browne]

> PL/1 was certainly pegged as the successor to both COBOL and FORTRAN;

And of Algol-60, simulation languages, and a few others, with an interface
giving more access to the underlying operating system than usual in that era.
It was a common joke at the time that PL/I enthusiasts all had dilated eyes,
nervous addicted bodies, and were repeating "More... more..." to no end! :-)

--
François Pinard http://www.iro.umontreal.ca/~pinard

François Pinard

unread,
May 3, 2002, 12:09:38 PM5/3/02
to
[Alex Martelli]

> I find Python's print convenient for debugging purposes, and that's
> about all.

Same here. For real output when I control everything, the simplest is to do:

write = sys.stdout.write

and then:

write(DATUM)

`write' will write DATUM exactly, with nothing added.

I see `print' as useful when used interactively, or else, as debugging
statements in batch scripts. I gave myself the rule, which I follow very
strictly, of never using `print' into a production script. I use editing
commands to blindly comment all remaining `print' when something goes
into production. This is convenient and useful for me.

It is loading more messages.
0 new messages