Why Python?

Cardinal Biggles had Eric in the comfy chair for over four hours before wringing this confession from him...

My first look at Python was an accident, and I didn't much like what I saw at the time. It was early 1997, and Mark Lutz's book Programming Python from O'Reilly & Associates had recently come out. O'Reilly books occasionally land on my doorstep, selected from among the new releases by some mysterious benefactor inside the organization using a random process I've given up trying to understand.

One of them was Programming Python. I found this somewhat interesting, as I collect computer languages. I know over two dozen general-purpose languages, write compilers and interpreters for fun, and have designed any number of special-purpose languages and markup formalisms myself. My most recently completed project, as I write this, is a special-purpose language called SNG for manipulating PNG (Portable Network Graphics) images. Interested readers can surf to the SNG home page at http://www.catb.org/~esr/sng/. I have also written implementations of several odd general-purpose languages on my Retrocomputing Museum page, http://www.catb.org/retro/.

I had already heard just enough about Python to know that it is what is nowadays called a “scripting language”, an interpretive language with its own built-in memory management and good facilities for calling and cooperating with other programs. So I dived into Programming Python with one question uppermost in my mind: what has this got that Perl does not?

Perl, of course, is the 800-pound gorilla of modern scripting languages. It has largely replaced shell as the scripting language of choice for system administrators, thanks partly to its comprehensive set of UNIX library and system calls, and partly to the huge collection of Perl modules built by a very active Perl community. The language is commonly estimated to be the CGI language behind about 85% of the “live” content on the Net. Larry Wall, its creator, is rightly considered one of the most important leaders in the Open Source community, and often ranks third behind Linus Torvalds and Richard Stallman in the current pantheon of hacker demigods.

At that time, I had used Perl for a number of small projects. I'd found it quite powerful, even if the syntax and some other aspects of the language seemed rather ad hoc and prone to bite one if not used with care. It seemed to me that Python would have quite a hill to climb as yet another scripting language, so as I read, I looked first for what seemed to set it apart from Perl.

I immediately tripped over the first odd feature of Python that everyone notices: the fact that whitespace (indentation) is actually significant in the language syntax. The language has no analog of the C and Perl brace syntax; instead, changes in indentation delimit statement groups. And, like most hackers on first realizing this fact, I recoiled in reflexive disgust.

I am just barely old enough to have programmed in batch FORTRAN for a few months back in the 1970s. Most hackers aren't these days, but somehow our culture seems to have retained a pretty accurate folk memory of how nasty those old-style fixed-field languages were. Indeed, the term “free format”, used back then to describe the newer style of token-oriented syntax in Pascal and C, has almost been forgotten; all languages have been designed that way for decades now. Or almost all, anyway. It's hard to blame anyone, on seeing this Python feature, for initially reacting as though they had unexpectedly stepped in a steaming pile of dinosaur dung.

That's certainly how I felt. I skimmed through the rest of the language description without much interest. I didn't see much else to recommend Python, except maybe that the syntax seemed rather cleaner than Perl's and the facilities for doing basic GUI elements like buttons and menus looked fairly good.

I put the book back on the shelf, making a mental note that I should code some kind of small GUI-centered project in Python sometime, just to make sure I really understood the language. But I didn't believe what I'd seen would ever compete effectively with Perl.

A lot of other things conspired to keep that note way down on my priority list for many months. The rest of 1997 was eventful for me; it was, among other things, the year I wrote and published the original version of “The Cathedral and the Bazaar”. But I did find time to write several Perl programs, including two of significant size and complexity. One of them, keeper, is the assistant still used to file incoming submissions at the Metalab software archive. It generates the web pages you see at metalab.unc.edu/pub/Linux/!INDEX.html. The other, anthologize, was used to automatically generate the PostScript for the sixth edition of Linux from the Linux Documentation Project's archive of HOWTOs. Both programs are available at Metalab.

Writing these programs left me progressively less satisfied with Perl. Larger project size seemed to magnify some of Perl's annoyances into serious, continuing problems. The syntax that had seemed merely eccentric at a hundred lines began to seem like a nigh-impenetrable hedge of thorns at a thousand. “More than one way to do it” lent flavor and expressiveness at a small scale, but made it significantly harder to maintain consistent style across a wider code base. And many of the features that were later patched into Perl to address the complexity-control needs of bigger programs (objects, lexical scoping, “use strict”, etc.) had a fragile, jerry-rigged feel about them.

These problems combined to make large volumes of Perl code seem unreasonably difficult to read and grasp as a whole after only a few days' absence. Also, I found I was spending more and more time wrestling with artifacts of the language rather than my application problems. And, most damning of all, the resulting code was ugly—this matters. Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.

With a baseline of two dozen languages under my belt, I could detect all the telltale signs of a language design that had been pushed to the edge of its functional envelope. By mid-1997, I was thinking “there has to be a better way” and began casting about for a more elegant scripting language.

One course I did not consider was going back to C as a default language. The days when it made sense to do your own memory management in a new program are long over, outside of a few specialty areas like kernel hacking, scientific computing and 3-D graphics—places where you absolutely must get maximum speed and tight control of memory usage, because you need to push the hardware as hard as possible.

For most other situations, accepting the debugging overhead of buffer overruns, pointer-aliasing problems, malloc/free memory leaks and all the other associated ills is just crazy on today's machines. Far better to trade a few cycles and a few kilobytes of memory for the overhead of a scripting language's memory manager and economize on far more valuable human time. Indeed, the advantages of this strategy are precisely what has driven the explosive growth of Perl since the mid-1990s.

I flirted with Tcl, only to discover quickly that it scales up even more poorly than Perl. Old LISPer that I am, I also looked at various current dialects of Lisp and Scheme—but, as is historically usual for Lisp, lots of clever design was rendered almost useless by scanty or nonexistent documentation, incomplete access to POSIX/UNIX facilities, and a small but nevertheless deeply fragmented user community. Perl's popularity is not an accident; most of its competitors are either worse than Perl for large projects or somehow nowhere near as useful as their theoretically superior designs ought to make them.

My second look at Python was almost as accidental as my first. In October 1997, a series of questions on the fetchmail-friends mailing list made it clear that end users were having increasing trouble generating configuration files for my fetchmail utility. The file uses a simple, classically UNIX free-format syntax, but can become forbiddingly complicated when a user has POP3 and IMAP accounts at multiple sites. As an example, see Listing 1 for a somewhat simplified version of mine.

Listing 1

I decided to attack the problem by writing an end-user-friendly configuration editor, fetchmailconf. The design objective of fetchmailconf was clear: to completely hide the control file syntax behind a fashionable, ergonomically correct GUI interface replete with selection buttons, slider bars and fill-out forms.

The thought of implementing this in Perl did not thrill me. I had seen GUI code in Perl, and it was a spiky mixture of Perl and Tcl that looked even uglier than my own pure-Perl code. It was at this point I remembered the bit I had set more than six months earlier. This could be an opportunity to get some hands-on experience with Python.

Of course, this brought me face to face once again with Python's pons asinorum, the significance of whitespace. This time, however, I charged ahead and roughed out some code for a handful of sample GUI elements. Oddly enough, Python's use of whitespace stopped feeling unnatural after about twenty minutes. I just indented code, pretty much as I would have done in a C program anyway, and it worked.

That was my first surprise. My second came a couple of hours into the project, when I noticed (allowing for pauses needed to look up new features in Programming Python) I was generating working code nearly as fast as I could type. When I realized this, I was quite startled. An important measure of effort in coding is the frequency with which you write something that doesn't actually match your mental representation of the problem, and have to backtrack on realizing that what you just typed won't actually tell the language to do what you're thinking. An important measure of good language design is how rapidly the percentage of missteps of this kind falls as you gain experience with the language.

When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features!

This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process.

Not that it took me very long to learn the feature set. I wrote a working, usable fetchmailconf, with GUI, in six working days, of which perhaps the equivalent of two days were spent learning Python itself. This reflects another useful property of the language: it is compact--you can hold its entire feature set (and at least a concept index of its libraries) in your head. C is a famously compact language. Perl is notoriously not; one of the things the notion “There's more than one way to do it!” costs Perl is the possibility of compactness.

But my most dramatic moment of discovery lay ahead. My design had a problem: I could easily generate configuration files from the user's GUI actions, but editing them was a much harder problem. Or, rather, reading them into an editable form was a problem.

The parser for fetchmail's configuration file syntax is rather elaborate. It's actually written in YACC and Lex, two classic UNIX tools for generating language-parsing code in C. In order for fetchmailconf to be able to edit existing configuration files, I thought it would have to replicate that elaborate parser in Python. I was very reluctant to do this, partly because of the amount of work involved and partly because I wasn't sure how to ascertain that two parsers in two different languages accept the same. The last thing I needed was the extra labor of keeping the two parsers in synchronization as the configuration language evolved!

This problem stumped me for a while. Then I had an inspiration: I'd let fetchmailconf use fetchmail's own parser! I added a --configdump option to fetchmail that would parse .fetchmailrc and dump the result to standard output in the format of a Python initializer. For the file above, the result would look roughly like Listing 2 (to save space, some data not relevant to the example is omitted).

Listing 2

Python could then evaluate the fetchmail --configdump output and have the configuration available as the value of the variable “fetchmail”.

This wasn't quite the last step in the dance. What I really wanted wasn't just for fetchmailconf to have the existing configuration, but to turn it into a linked tree of live objects. There would be three kinds of objects in this tree: Configuration (the top-level object representing the entire configuration), Site (representing one of the sites to be polled) and User (representing user data attached to a site). The example file describes five site objects, each with one user object attached to it.

I had already designed and written the three object classes (that's what took four days, most of it spent getting the layout of the widgets just right). Each had a method that caused it to pop up a GUI edit panel to modify its instance data. My last remaining problem was somehow to transform the dead data in this Python initializer into live objects.

I considered writing code that would explicitly know about the structure of all three classes and use that knowledge to grovel through the initializer creating matching objects, but rejected that idea because new class members were likely to be added over time as the configuration language grew new features. If I wrote the object-creation code in the obvious way, it would be fragile and tend to fall out of sync when either the class definitions or the initializer structure changed.

What I really wanted was code that would analyze the shape and members of the initializer, query the class definitions themselves about their members, and then adjust itself to impedance-match the two sets.

This kind of thing is called metaclass hacking and is generally considered fearsomely esoteric—deep black magic. Most object-oriented languages don't support it at all; in those that do (Perl being one), it tends to be a complicated and fragile undertaking. I had been impressed by Python's low coefficient of friction so far, but here was a real test. How hard would I have to wrestle with the language to get it to do this? I knew from previous experience that the bout was likely to be painful, even assuming I won, but I dived into the book and read up on Python's metaclass facilities. The resulting function is shown in Listing 3, and the code that calls it is in Listing 4.

Listing 3

Listing 4

That doesn't look too bad for deep black magic, does it? Thirty-two lines, counting comments. Just from knowing what I've said about the class structure, the calling code is even readable. But the size of this code isn't the real shocker. Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it.

To say I was astonished would have been positively wallowing in understatement. It's remarkable enough when implementations of simple techniques work exactly as expected the first time; but my first metaclass hack in a new language, six days from a cold standing start? Even if we stipulate that I am a fairly talented hacker, this is an amazing testament to Python's clarity and elegance of design.

There was simply no way I could have pulled off a coup like this in Perl, even with my vastly greater experience level in that language. It was at this point I realized I was probably leaving Perl behind.

This was my most dramatic Python moment. But, when all is said and done, it was just a clever hack. The long-term usefulness of a language comes not in its ability to support clever hacks, but from how well and how unobtrusively it supports the day-to-day work of programming. The day-to-day work of programming consists not of writing new programs, but mostly reading and modifying existing ones.

So the real punchline of the story is this: weeks and months after writing fetchmailconf, I could still read the fetchmailconf code and grok what it was doing without serious mental effort. And the true reason I no longer write Perl for anything but tiny projects is that was never true when I was writing large masses of Perl code. I fear the prospect of ever having to modify keeper or anthologize again—but fetchmailconf gives me no qualms at all.

Perl still has its uses. For tiny projects (100 lines or fewer) that involve a lot of text pattern matching, I am still more likely to tinker up a Perl-regexp-based solution than to reach for Python. For good recent examples of such things, see the timeseries and growthplot scripts in the fetchmail distribution. Actually, these are much like the things Perl did in its original role as a sort of combination awk/sed/grep/sh, before it had functions and direct access to the operating system API. For anything larger or more complex, I have come to prefer the subtle virtues of Python—and I think you will, too.


All listings referred to in this article are available by anonymous download in the file ftp.linuxjournal.com/pub/lj/listings/issue73/3882.tgz.

Eric Raymond is a Linux advocate and the author of The Cathedral & The Bazaar . He can be reached via e-mail at (esr@thyrsus.com).



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Why Python

Joseph Q.'s picture

Sabes mucho ingles?
si sabes mucho ingles primero tienes que ir a http://www.catb.org/%7Eesr/faqs/ para ser un hacker, no un cracker

IronPython for .NET and MONO

Anonymous's picture

Yeah Eric, it certainly is interesting. Now that Jim has released IronPython for both .NET and MONO/Linux we finally have access to a huge class library and integration between languages. For me this means that Python might finally be useful.

Python in 2000, but Ruby in 2004

Anonymous's picture

Back in 2000, Python was the clear choice for scripting.

But in 2004, Ruby is the way to go and rapidly gaining momentum.

Back in 2000, the documentation for Ruby in English was virtually non-existent. But several English Ruby books came out in 2002 and the language is rapidly winning converts from both Perl, Python. In Japan, Ruby is already more popular than Python.

In a nutshell, Ruby's author took the best of Perl, Smalltalk and other languages when coming up with Ruby--it literally stands on the shoulders of giants and it clearly shows.

While designed from the ground up to be purely object-oriented, it also recognized the practical needs of programmers and allows provides shortcuts so that one-liner scripts are both possible and easy-to-understand. There are also numerous examples of design patterns (made famous by the "gang-of-four") implemented using Ruby.

If you like Python, check out Ruby. Once you try it, chances are good that you'll not only be productive, but have fun programming.

You'll also find the #ruby-lang IRC channel rather friendly to a "ruby nuby". Compare this to the rather notoriously unfriendly IRC channel of another scripting language (hint: it is not Python's channel).

Ruby 1.8.1 is the current release and Ruby 1.8.2 is scheduled for release around July 7, 2004. Check it out and see what the future of scripting is all about.

For a neat comparison of short snippets written in C++/Java/Python/Ruby, see the Rosetta Stone at:

Ruby Pages:


Well, python is still making the headlines!

Raqueeb Hassan's picture

Yes, Ruby is great, but when it comes to unix scripting, python still rocks. Thanks for the ruby links.


Raqueeb Hassan

Ruby vs. Python

Anonymous's picture

Unless its been added in the last few months, Ruby does not support Unicode. Python does. For me, that by itself rules out Ruby for many applications.

Ruby doesn't really offer any

Anonymous's picture

Ruby doesn't really offer any significant advances in expressiveness over Python, but it borrows a ton of misfeatures from Perl. Net result for me: Ugh.

Re: Why Python?

Anonymous's picture

This guy writes very well! Does that proves that writing clean code can be a subset of writing clean? (and relevant, and expressive, and so?)

% Besides a mathematical inc

Anonymous's picture

Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital
asset of a competent programmer.

-- Edsger W. Dijkstra

$I .* see .* \what you|u mean

Anonymous's picture

$I .* see .* \what you|u mean|t \[in a way\]


Anonymous's picture

Seldom do I use the pithy acronym that is LOL, but this comment most certainly caused me to post:



Anonymous's picture


Re: What is python

Anonymous's picture

chileam hello

One Python vs. Perl question.......

Anonymous's picture

I have not (yet) truly begun exploring the mysteries of Python. I have been struggling for some time now with Perl, and I've run up against a particular roadblock that I'm curious whether Python will let me pass.

I have an existing program (written by someone else, in FORTRAN) with a command-line-driven user interface and a graphics extension (written by me, in C) that accepts arrays and displays them in 2D format. This program works fine under UNIX, but now I have to rewrite the graphics to work under MS-Windows, preferably in a fashion that is not platform-specific.

The problem I've been butting my head against with Perl is that it seems very difficult and esoteric to call a module (such as Tk) from a Perl function that is called from C. I'm also having problems with passing arrays by reference between Perl and C. The numerical address comes through, but I can't dereference it.

Is there a (relatively) trivial way around these issues in Python? If so, I'll stop wasting my time on Perl......

try: http://starship.python.n

Anonymous's picture

Re: One Python vs. Perl question.......

Anonymous's picture

If all else fails, you could take your existing C code and wrap it using the Python API to create a new module (called extending). Python could then act as the intermediary between your low-level C algorithm and whichever GUI you want to use (Python does interact pretty well with Tk via Tkinter).


Re: Why Python?

Anonymous's picture

keep in mind that this is directly from ESRs homepage ...

Re: Why Python?

Anonymous's picture

OMFG.... this is one of hardest to read posts i have ever seen (and as a long time CS admin i know what i'm talking about).

Have you ever considered using at least some structure in your sentences? An occassional point or a line break can do wonders :)

(BUT: no offense meant)

To the topic itself. I started with python several years ago. Before that i wrote a couple of applications (mainly web applications) in several other languages (NOT php! I will never touch that). I was amazed how quickly i was able to generate complete applications. I was also amazed, as a notoricly lazy typer, that i was able to quickly read and understand code after several months not touching the code despite the lack of proper comments or documentation.
That doesn't mean i dont comment or document. I'm just not doing it very much.
I think i once read somewhere that the ratio of comments in a code that is necessary for a reader to understand what it does to the code itself is a hint on how readable and well designed a language is.
Well, my c / c++ experience was i had to write nearly as much comments as code. In python i needed a small comment only in parts where something really important happened (i am using docstrings a lot though). In other languages like VB / VBScript ... I commented and documented a lot with the result that i still was unable to read the code afterwards...

Yay, Python... i see no reason to use another language for my day-to-day tasks

Re: Why Python?

Anonymous's picture

I am convinced, and though I was always intrigued with the prospect of a language that enforces indentation, I was put of by the fact that programmers I know, never mentioned the language.

I read your article last week, and I began studying Python.
I write small utilities now, something which have taken me considerably longer in any other language I have been programming in.

Thanks Guido, and most of all. Thanks Eric, in my world, my first choice of demigod, is probably you.

Re: Why Python?

Anonymous's picture

I've used another language that enforces indentation: COBOL.

Python is a breeze after that (in fact, most languages are).

Re: Why Python?

Anonymous's picture

I used another language where indentation matters: OCCAM. This was developed to support parallellism in a programming language, and it did run on so called Transputers.

Transputers are (were?) processors with integrated communication links dedicated to build systems with a large number of CPUs. Each CPU has its own memory. The communication links are directly supported from the instruction set. Interestingly a task scheduler is integrated into the instruction set.

For my MsC thesis I created a piece of assembly able to monitor the scheduling. The output of all CPUs (we had a box with 32 of them) was then fed into a tool (on a Sun, in C) which created a report about the achieved parallellism of the application. Target was to automatically redistribute the application over the CPUs to gain more performance; measure again, and iterate until the optimal performance is found. Ah, the good old days!

I think using the indentation is not so bad: a lot of times I have seen code with correct indentation but wrong meaning (the funny semicolon-after-an-if-statement trick in C...).

So I think I will try Python, it sounds great.

Eric Koenders

Re:hint is needed?

Anonymous's picture

goddamn. this is a hard one!

couldn't tell what the message was.

tried pyhton standard library for simple encoders/decoders but with no success.

my guss is that the whitespaces should remain intact.

what the hell is "g555 5t 55 5 5 5 5" - i guess that can be a breaking point.

also note the word "james" at the end of the first sequence. is it on purpose?

let us solve this godamn puzzle....

Re:hint is needed?

Anonymous's picture

You might try searching CPAN for the "Lingua::31337" module to decode this using Perl.

Re: Why Python?

Anonymous's picture

You ask Why ?

It is simple. You are really not at the right place to talk about cracking because every one here are or want to be hacker (and it is not the same thing trust me > go see the jargon file).

Now you can't make you any friend here because everybody hate you (although you are anonymous).

In other words, in the Internet, there is neutral places, places to encourage the good creation and places to encourage destruction. And you are talking about destruction in a place where we encourage good creation.

Think about it

(I am finishing writing and I see the the "Why ?" was posted in 2002 > anyway)

Re: Why Python?

Anonymous's picture

This makes no sence .This is a sting all computers on this web site will be shut down a police car is speeding to your house now!

Re: Why Python?

Anonymous's picture

If you are new to programming, and wish to use Python as you're first language, which I recommend, havind tutored many undergraduates, you can't go wrong with "How To Think Like A Computer Scientist: Learning With Python". It can be downloaded at http://www.ibiblio.org/obp/. If you are sincere, and work through this text, you will be well on your way to reaching your goal as a programmer.

Regards to all.

Re: Why Python?

Anonymous's picture

My apologies, as I typed an incomplete link to the download. It is more accurately


Re: Why Python?

Anonymous's picture

Re: Why Python?

Anonymous's picture

Great book. Essential reading.

Re: Why Python?

Anonymous's picture

Thanks Eric. You have put into words much of my own experience and understanding of the Perl vs Python debate. Over the last 20 years, I have coded in a variety of languages (not as many as yourself) and even written a few simple ones, and I have been very impressed with Python. My most productive language in 95-97 was Perl but, like you, I was dismayed at how hard it was to maintain my own code. In 97 I discovered Python and found it a very good match for how I build solutions in my head. It is clear, maintainable, concise, and well supported. Thanks again. -- Mike.

Re: Why Python?

Anonymous's picture

Fellow Coders,

Perl is very readable and maintainable when properly coded and commented. Any programmer can write tortured code in any language (not that this is the case with ESR).

Why should you use Perl and not Python? How about the breadth of available modules for Perl. Python is pale in comparison. It will be a long time before I switch Perl for python; there aren't enough libraries.

Note, I do not disagree with anything ESR said. Python is indeed very clean and readable. I am just more concerned with coding speed at this stage in my life. I have to solve the problem, quickly.

Re: Why Python?

Anonymous's picture

Missing? What's missing in Python? In the two years I've worked with Python, I haven't needed any library that wasn't couldn't be found for Python. Most everything I've needed is in the standard library and what little that isn't I found through Starship.

If there is anything missing, please post what that is so I can write it.

Re: Why Python?

Anonymous's picture

The one thing I want python to have (so I hope you write it :) ). Is the equivalent of perl's Spreadsheet::WriteExcel which is a library to write the binary excel file format. I think this would be a great contribution to python, or maybe its me being selfish. Good luck!

Re: Why Python?

Anonymous's picture

Why not try using the XML and ZIP tools to make OpenOffice.org Calc files? There's probably a way to do a format-convert call to OpenOffice.org from Python.

why not ride a bike to icelan

Anonymous's picture

why not ride a bike to iceland instead of flying a plain?

Re: Why Python?

cstromberger's picture

Perl is very readable and maintainable when properly coded and commented. Any programmer can write tortured code in any language

Not buying it. Here's an example from a small script I wrote today.

$sysmsg =~ s/&/

sysmsg = sysmsg.replace('&', '

The Perl version is not readable unless you know Perl well. There's nothing intuitive about it, from the '$' to the '=~' to the bizarre regex substitution thing. The Python version is readable and clear to anyone with just rudimentary programming skills.

Re: Why Python?

Anonymous's picture

I find '$' quite useful in perl. when I define new variables, I don't have to worry about conflicting with key words. you can actually define a variable with the name 'if' by '$if'.

I find python confusing on the other hand.

e.g. sysmsg = sysmsg.replace('&', ' ')

what if you wrote "sysmgs = sysmsg.replace('&',' ')"

there is a small typo! In perl "use strict;" would find that for you, but python has no equivalent yet. Also, I find it quite exhausting to have to remember the different "runtime object" types. if sysmsg was declared an interger or set an interger by accident somewhere, it won't show or warn you like in Java during compilation!

Python class types is quite confusing at times. e.g.

a = 3

b = "2"

c = a + b

would cause an error, while in perl

$a = 3; $b = "2"; $c = $a + $b; is functional.

what matters here is if you had taken b from command line.

b = raw_input()

would return a "string" and you have to explicitly convert it into an integer. But there is no where to specify what "b" is. you can use it as an integer and then a string.

It really confuses me!!!


perl types are confusing at first('$', '%', '&', '@'), but if you take the time to understand them and then learn ooperl, it might become quite convenient to use. (with -w and use strict guarding the design.)

the main reason that made me thought about converting to python is that perl object codes needs more typing than python. in perl "$object->command();" while in python "object.command()" has less typing. Well, just a thought after studying perl for 6 months.

Re: Why Python?

Anonymous's picture

I've worked on QBasic (I was 8 and it was all my father knew), fiddled with VB (Hey, I was only 12), tested the water with C++ (It was a high school course), learned a bit of Java, Wrote a some things in Perl (I'm no expert), and I'm currently working with Python. I haven't used ooperl but I can see what you're talking about.

I did notice some of those annoyances but, in order to prove to myself that they couldn't have done any better, I traced out the changes one generation after another. ("Ok, if I fix this then this needs to be changed but if I do that, then it introduces this problem.") I couldn't find any better way.

Re: Why Python?

Anonymous's picture

In the past couple of months, I have been learning both Perl (as required by my work) and Python (just for fun). So far, I have found that having to remember the "&", "@", etc. for variables rather annoying when just working with variables...but Perl can become very difficult to use when you attempt to create a data structure of a data structure, precisely because of this syntax. As I happen to like making lists of dictionaries of lists sometimes, this makes Perl much more difficult for me to use.

So far, the only shortcoming I've seen in Python on this point is the inability to create anonymous functions (ignoring the simple and limited lambda functions). This is easy enough to get around, though, so it isn't a major problem, just an inconvenience.

Re: Why Python?

Anonymous's picture

I find '$' quite useful in perl. when I define new variables, I don't have to worry about conflicting with key words. you can actually define a variable with the name 'if' by '$if'.

If you actually want to name variables "$if" or after other keywords, then yes, you will fit right in with Perl.

Variable names

Anonymous's picture

One of the problems with using variable names that happen to coincide with reserved words is confusing the variable with the reserved word (i.e., forgetting the $).

As far as Python is concerned (and programming in general), you should not write your programs where the functions/variables/reserved words/etc. could be confused - especially when you have to come back to the program later to update it.

As far as Perl's use of (&,$,@,whatever), you can get the same functionality by using a prefix for your variables; i.e.:

p_if = (something)

The other item is if you use a predefined prefix for variables throughout your code, it becomes easier to trace the variable in other modules as well.

Proper programming should allow the flow to be easily distinguishable anyway. As ESR pointed out, even people comfortable with Perl may have problems getting reaquainted with the language after even a short hiatus.

Re: Why Python?

Anonymous's picture

Many thanks for the example, that clears up so much inner contention I had as to the real value of Python and of Perl.

Re: Why Python?

Anonymous's picture

Shouldn't there be a smiley after this comment?

Re: Why Python?

Anonymous's picture

what is: Perl: $sysmsg =~ s/&/ /g; Python: sysmsg = sysmsg.replace('&', ' ') supposed to mean?

Re: Why Python?

Anonymous's picture

it replaces ever instance of "&" with a " " in the string sysmsg.

Re: Why Python?

Anonymous's picture

Define a vairable called $sysmsg, which when called does a global substitution of & with a wjite space ( I think)

Re: Why Python?

Anonymous's picture

Perl: $sysmsg =~ s/&/ /g;

Python: sysmsg = sysmsg.replace('&', ' ')

Both lines do the same thing. Python is clearer.

Re: Why Python?

Anonymous's picture

I've been away from programming for over 10 years now, (excluding some Microchip PIC assemblier) and I decided to choose between Perl and Python as the first language I'd try to pick up after a long hiatus. I ended up with Python. Like ESR, I was orginally turn off by Python's significant indentation, but Perl's "many ways" approach turned me off even more. (The comment I once read about different 'dialects' of Perl based on how a programmer learned to do things was the final bit of information I needed before making my decision.)

As ESR stated in his article, human time is far more valuable than computer time. (Hence he didn't consider running back to C.) So the quantity of modules available in a language is an important consideration, or is it?

How many modules do you use on a day to day basis? 10? 50? 100?? Look at what you actually use and then check to see modules exist. Unless you're doing some pretty esoteric things, I'd be surprized of Python doesn't already have them.

Re: Why Python?

Anonymous's picture

There's no doubt that Perl's greatest strength is cpan. There are an enormous number of third party libraries available. But the quality of cpan modules is uneven- some contain significant bugs, so it's a bit of work to assess whether or not cpan modules are safe to use.

As for the standard libraries, I think that Python's standard library is actually somewhat more complete than Perl's. There are also a _lot_ of third party Python libraries around, and for some things Python has better libraries than Perl. Gui programming is definitely one of them. Python has bindings to an awful lot of Gui libraries, some of which are IMHO much more useful than Tk. And the asyncore/asynchat library for asynchronous socket programming is the best library for developing network servers that I've ever used.

I think that Perl is pretty much the best language around for what it is best at: writing short scripts for processing text, and performing system calls. Python is good for that sort of thing as well, but I find Perl's regex syntax more comfortable than Python's, and I really like how succinct Perl code can be when I'm writing simple scripts. But for medium and large applications, particularly end user apps requiring a complicated GUI, or apps requiring a complicated OO design, I prefer Python to anything else except Smalltalk.

perl's greatest strength is c

Anonymous's picture

perl's greatest strength is cpanel not cpan


Re: Why Python?

Anonymous's picture

"Lean" some writing skills, O alien(ated) one...

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState