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.

Resources

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).

______________________

Comments

Comment viewing options

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

Good read

Anonymous's picture

As someone who just started with python, I found that it was much more verbose and time-consuming to write those short little programs and have some doubts about its efficacy and proclaimed 95% goodness RDI.

I guess now I feel more confident that it's not just me. Perl for short and quick, Python for things I'll be looking at again.

Good article

cmnorton's picture

This was helpful. Having programmed in PL/I, C, C++, Bliss, and other languages, the space indentation of Python initially put me off. I am starting to use it for small projects.

Something that helped me

Graphate's picture

this is what helped me out a little bit... if anyone really reads this anymore:
http://www.apple-group.com/forums/showthread.php?p=37923

2¢ out.

All the comments

Anonymous's picture

All the comments the author made about Perl seem to refer to Perl 4, and he seems to not have even the slightest clue about CPAN and the modern tools (Perl::Critic et al.) it offers to automate the enforcement of coding standards and best practices across a large developers team.

Ruby is worth a look. In

Anonymous's picture

Ruby is worth a look. In some ways, it is cleaner than Python (for example, lots of functions that should have been methods in Python are methods in Ruby).

My experience exactly

Eric Standlee's picture

After trying to do something in MSVB for two weeks, I was able to use python to accomplish it in 2 days from a cold start.

Don't use it all of the time, but love it.

python tutorial

Anonymous's picture

python tutorial on http://www.linuxenv.com

Just a couple Python questions

Ron Haines's picture

I am considering taking on one or two more languages for the purpose of creating public release applications. Having read your article "Why Python?", I must say it has certainly sparked my interest.
My questions are as follows...

Does python produce a compiled distributable program, or as one readers comment appeared to hint at, must an end user have "Python installed on there machine to run Python apps?

My main interests are programming languages that can produce compiled programs that can be used by the end user without the need of installing the programming language itself.

(Hmm.. did i word the right , hope so) In any case I will continue researching this and will probably discover the answer on my own very shortly, but answering this here could also help others with similar questions.

Thanks
=MANTA=

Interpreted

Anonymous's picture

Python is strictly an interpreted language. However, one can create a "frozen binary" which does create a standalone executable. py2exe, PyInstaller, and freeze are the three big ones, with former one being for Windows executables and the latter two being for UNIX and UNIX-like. This allows others to run Python executables without having it installed. However, it does not actually compile anything.

guten morgun

Anonymous's picture

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 Those who want to move the 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.

hi. can i install python on

Anonymous's picture

hi. can i install python on Windows XP? what version?

http://www.f1f7.net/vb/

Python is used by Windows XP

maskedfrog's picture

Python is included as a utility in XP.
It's already there :)
Came as quite a surprise to me at first.
However, seeing how useful a scripting language Python
is it really should come as no shock.
Details in implementing you own python scripts shouldn't be
too hard to find. Google can be a dear friend :^D

Python is not included on

Anonymous's picture

Python is not included on all XP Installations. HP and maybe a few other companies preload this on computers, because they have admin tools written in python. If you were to just buy XP, it would not already have it installed.

teach me

from malaysia's picture

hello..

anyone can teach me how to hacking..

pls..

are_raul92@yahoo.com

teh lol

Anonymous's picture

format c:\

lol

Anonymous's picture

format c:\
did not work as intended but I guess that is because linux isn't windows =)

i liked it

sohail's picture

is there any one who can teach me the basics of hacking

Reply to "Is there anyone who can teach basics of hacking"

Anonymous's picture

Email your ip address to me and I'll send you an email . :=)

Oh

Andrieux's picture

IP addresses mean nothing these days. You wouldn't be able to do anything with it, anyways.

"Email your ip address to me

Anonymous's picture

"Email your ip address to me and I'll send you an email . :=)"

Brilliant.

Thank you!

Anonymous's picture

Thank you for taking the time to write this informative and entertaining article. I very much enjoyed the natural flow of your writing style and, despite a lack of previous efforts to learn a programming language, you have persuaded me to give Python a try.
Nine years later and this article is still having an impact... now I'd say that should earn at least gold star for content!

Thank you!

pls i dont know basic

Anonymous's picture

hello pls i dnt know anything about hacking not even the basics i will b very gratefull if a prof will teach me my mail is ceiknw@yahoo.com

Quickest way to learn Python

Anonymous's picture

Dawson, M. “Python Programming for the absolute beginner” Latest edition. ISBN 1-59863-112-8

Seriously. Give it a try.

(Note: for BEGINNERS)

Best Python book for n00bs:

Anonymous's picture

Dawson, M. “Python Programming for the absolute beginner” ISBN 1-59863-112-8

Work though this, try all the examples and you'll be a l33t h@x0r in no time.

Disclaimer: I have nothing to do with the author or the publishers, just a happy customer.

learning in a few days

soundandfury's picture

So, esr is pretty stunned that he learned Python in a few days. Well, how about C? I went from knowing nothing but BASIC (in which I have been hacking for several years) to fairly good competence in C, in about a fortnight on and off. And I'm not in any way a wizardly hacker, I'm an adolescent who taught myself programming with BASIC.
So I think the moral of this is that /most/ programming languages are easy to learn if you've already learnt the practices in another language. Either that, or it's actually worthwhile spending longer than is considered normal in BASIC before going elsewhere.

In my first week I wrote a daemon to watch a network share and grab files from it to move somewhere else - configurable on the command line. In my second week, Newton-Raphson iterations (with functions stored as binary trees). I haven't tried Python, so I don't know how easy it is, but esr's description of how easy he found Python sounds a lot like my own experiences teaching myself C. Maybe C isn't as hard to use as esr suggests... OK, so neither of these were robust production-standard code, but they're not easy to break...

Learning the syntax of a

Anonymous's picture

Learning the syntax of a language and becoming an expert in a language are two different things.

Multiple Languages

Ron Haines's picture

Esr's opinion carried weight because the comparison is based on my not one or two languages.

As for finding it easier to learn multiple languages...
Yes, knowing many languages myself I would say that each language gets a little easier to pick up, but I am speaking from my own relative point of view of course.

My first language was like most, BASIC. Finding that too slow for video games and other graphics intensive use I went for the throat and learned 6502 and 6510 ML (Yes, I am dating myself LOL especially since I didn't get into programming until I was 30!), after that I learned ASM.

When the internet bloomed in the 90's I switched to HTML and scripted languages such as ASP and PHP, having mastered those I am now seeking out one or two modern compiled languages with which to write LINUX, WinOS desktop and I-Phone apps.

What I have found that makes subsequent languages easier to learn is the basic components all have in common such as Loops, Conditional Branches, Subroutines/Functions. Looking at them this way in my head (perhaps because of my experience in ML and ASM) I can quickly see relational functionality between almost every language I have learned so far. The tricky part for me seems to be keeping the syntax quirks for multiple languages straight in my head.

Since you are only on your second language I wanted share my thoughts on the similarities and add a suggestion (if you are truely hungry to master the machine) to try and learn at least one of the root languages ML or ASM. I realize that most poeple call them dead languages but I can promise you that even if you never write anything in them, one you have learned ML or ASM you will never see the way a computer thinks the same way again.

Benefits of knowing ML in a nut shell...

There is no such thing as copy protection.
Anything that can be written can be unwritten.
If you can envision it in your mind you can teach a computer to do it.

That doesn't mean I advocate cracking software, just that you will have the deepest understanding of how computers think and operate possible, and those principles and fundamentals will help you in whatever programming language you are using.

=MANTA=

ESR spoke as a veteran of multiple languages

Jonathan Hayward's picture

It may well be true that your second language is easier than your first, but ESR was astonished after studying [mumble] dozen languages and dabbling with Deep Magic.

If someone says, "My second language was so much easier," that's par for the course. If someone says "My twenty-fifth [or whatever] language is so much easier,"... maybe it really IS the language.

Written as someone who had studied a few languages, picked up Python... and thinks maybe it really IS the Python.

i like programming in python

anonymous's picture

i like programming in python but (and) the problem is when writing gui applications.is there anyone who can tell me the best gui package.And i started my programming in assembly and i don't know the qualities(the advantages of ) python on java or C please tell me about the differences.thank you very much

RE: Gui programming in python

victor miclovich's picture

Well, we have several GUI packages for python, although many are third party packages. They include, but aren't limited to this list below:
-wxpython
-tkinter
-qt
-PyQt (licensed for commercial purposes but free when used on open source projects)
-Swing (when using Python with Java classes... or Jython)

There are other numerous gui packages, like I said but others mostly are for other purposes usually scientific (modeling) such as Visual python....

I hope this could help :)
Vic

TO ALL THE POEPLE VISITING THIS PAGE ASKING HOW TO HACK...

Anonymous's picture

The guy who wrote this article (Eric S. Raymond) wrote a nice little essay that has everything you need to know: http://www.catb.org/~esr/faqs/hacker-howto.html

(and if you're under 25 you may have to look up the word "phreaking" in wikipedia, I did the first time I read that document)

tcp, database: python

tdb8's picture

one year ago i was (almost) new to linux (ubuntu), i knew no python, zero, at all.

my need was to store and retrive records to/from a database (any free one) depending on the tcp input stream both to display and store.

i needed it fast and to use immediately. one google search and python with apropriate library was on the firsts results.

Learning and implementing, one week in spare time.
the code could be prettier (not a programmer for years) but it works!

now, i didnt know about the easy interaction with graphics, and makes me willing to trash the terminal output and draw a nice window.

python for windows xp

Anonymous's picture

hi. can i install python on Windows XP? what version?

I got Python 3.0 installed

Toyman's picture

I got Python 3.0 installed in Windows XP.

Bad Bad Bad, if you have

Anonymous's picture

Bad Bad Bad, if you have python 3.0 or higher get rid of it. It does not work at all with any of the other python versions. It is not the same language as 2.x

Actually, for someone new to

Anonymous's picture

Actually, for someone new to the language, 3.0 is best as long as they don't need extensive libraries. On the whole, the syntax is much cleaner and the language itself is less redundant. Quit spreading FUD.

My problems (IMHOIMHOIMHO)

salmonix's picture

My problems (IMHOIMHOIMHO) with the writing is simply it is again a one sided Perl vs.Python article with some mistakings. First: I am not a great Perl hacker, but I can easily reread my 2000 lines of code - if one has difficulties with it, then should reconsider the style. It is true that you can write obscure lines in Perl - as you can use only idioms in speach that only native and local speakers can understand. But it is a different style to speak among friends (short dirty codes for yourself) and to the audience (clearly articulated code for others). Not understanding the difference is your shame.
Then: Python is easy to learn. For whom? Reading Python programming it really seems easy for me: nice legible classes, methods, easy to use documentation etc. But I am somewhat AFTER Perl. Simply witout knowing any programming language Python could also bring difficulties. It is impossible to judge how easy it is to learn Python once you know e.g.Perl. Then you can only judge if Python appeals you more or not. But do not confuse the terms. For me Ocaml is an interesting challenge and no shock at all. Is Ocaml easy to learn???? For I have the opposite feeling with C.
Python is a nice language with its one way to do it method, where problems of style is less a matter. But for some it is never appealing. Some state that programming is not art but engineering, but for some during programming sometimes the intuitive part of the brain (a helpful part) plays with the possibilities of style, leaving the rational part a bit of sleep, offering a different angle. As in life some people has style like a franchise hamburger, the same is with coding probably. Some people feel Python boring with annoying intendation and play with orcish or latin modules writing useless but fun code, and some people feel Perl confusing in change. As tools both languages are good tools with different emphasis. And being a Python fun I would not miss Perl. And vice versa.

Why Python?

wcdsugpy's picture

This article is timeless and timely. The former accurately portrays the yearning for the right tool to do the job. Sleepless nights and turning and tossing. The latter now prompts me to revisit a project put aside for the last 4 years. I encountered Perl at about the time that the article was written to process Excel files. I hated and do hate manual data entry and carve up scripts and makefiles to automate the task. Then the idea of a GUI came up and attempted to develop a GUI for the end users using the Win32 OLE Perl Module. And had a look at Perl/Tk but the program became increasingly lengthy and I had to put it aside. That's 2004.

Your piece on Pyhton objects for the fetchmail conf is inspirational and may be just what I need. I had looked at Python two years ago, documented my encounter but now will revisit it again.

For small jobs on data processing, Perl still shines but for bigger projects such as the one I have and another that was floated around in 2001, Python may be the right tool for it.

It will be an adventure.

Thank you

wcdsugpy@yahoo.com

Ruby

Leslie Viljoen's picture

Try Ruby though. Python is interesting, but Ruby is the proper replacement for Perl. I had to dump my Perl-childhood the day I found Ruby.

+1

Anonymous's picture

+1

Pathetic

Jonny's picture

Are all these comments just 11 year olds script kiddies trying to become "hackers"? Maybe they should research about what a hacker actually is before writing a very long and pointless manifesto.

Don't waste your time with cracking...If you enjoy it still, become an ethical hacker.

I find it quite pathetic in my eyes...

Language Programs

The next Crash Override's picture

I really believe I could be a good addition to the hacker community because I read your how to become a hacker page at catb.org and I have the makings of a great hacker just don't know where to start so if you could hit me up at that e-mail address I would be forever grateful.

This is the Manifesto that I follow.

Another one got caught today, it's all over the papers. "Teenager Arrested in Computer Crime Scandal", "Hacker Arrested after Bank Tampering"...

Damn kids. They're all alike.

But did you, in your three-piece psychology and 1950's technobrain, ever take a look behind the eyes of the hacker? Did you ever wonder what made him tick, what forces shaped him, what may have molded him?

I am a hacker, enter my world...

Mine is a world that begins with school... I'm smarter than most of the other kids, this crap they teach us bores me...

Damn underachiever. They're all alike.

I'm in junior high or high school. I've listened to teachers explain for the fifteenth time how to reduce a fraction. I understand it. "No, Ms. Smith, I didn't show my work. I did it in my head..."

Damn kid. Probably copied it. They're all alike.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me.. Or thinks I'm a smart ass.. Or doesn't like teaching and shouldn't be here...

Damn kid. All he does is play games. They're all alike.

And then it happened... a door opened to a world... rushing through the phone line like heroin through an addict's veins, an electronic pulse is sent out, a refuge from the day-to-day incompetencies is sought... a board is found. "This is it... this is where I belong..." I know everyone here... even if I've never met them, never talked to them, may never hear from them again... I know you all...

Damn kid. Tying up the phone line again. They're all alike...

You bet your ass we're all alike... we've been spoon-fed baby food at school when we hungered for steak... the bits of meat that you did let slip through were pre-chewed and tasteless. We've been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now... the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn't run by profiteering gluttons, and you call us criminals. We explore... and you call us criminals. We seek after knowledge... and you call us criminals. We exist without skin color, without nationality, without religious bias... and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it's for our own good, yet we're the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can't stop us all... after all, we're all alike.

How to run a program

Anonymous's picture

Ok, so I downloaded Python, the newest version 2.5. And I have some writing experiance (I took a C++ class in highschool) and heard that this is a good language to start on. Anyway the C++ I used had a compiler, and i have no idea how to get my script to run on Python. Uhmm, you may also know that I''m running it on a laptop, Windows Vista. So thanks in advance for any help!

Install python on Vista

Lumax's picture

When you are looking for Information about installing Python on Windows Vista, I found something here .... Hope that helps.

how to

Anonymous's picture

i recently recieved a dell inspirion 1501 with amd64x2 and, for some reason, it refuses to let me download python. any suggestions?

You don't say what OS.

Anonymous's picture

You don't say what OS. If you're running Vista you need a .dll from the XP Win folder.

Vista w/Python: http://python-forum.org/py/viewtopic.php?=&p=12964

Since you run an AMD64, the Win thing to do, for Python, is 32-bit emulation. If you're running Linux, you've already got Python in 64-bit living color.

THE Comment

epat's picture

Basically - There are four types of people commenting on this:
1) Perl Zealots
2) Python Zealots
3) Wannabe Hackers (Wannabe Coders - to avoid confusion)
4) Wannabe Crackers.

First of all - for (1) and (2):
--------------------------------

Unless you program in both langauges fluently you shouldn't really be comparing readablility and certainly not flaming either of them.
I don't know perl so I am not going to compare the specifics in either langauge; but what I can tell you is that most large perl programs I have used on linux have had a LOT of bugs in them (and believe me when I say I am VERY good at finding bugs) so far, I don't think ANY perl program or script has lasted more than 5 minutes of me tweaking options before it has crashed and forced me to try and debug it. On the contrary, most python programs and scripts I have used do NOT crash within 5 minutes and even the badly written ones usually last me around about 10 minutes before I find something that breaks the program. Those are just from a users perspective although I admit that I am probably going to be slightly biased perhaps and maybe the more robust python programs are just dependent on what they are used for.

The other difference between perl and python from a user perspective is the speed. perl FEELS slower than python - feel free to prove me wrong on this one though - if you can - but don't bother unless you can either program both fluently as said or you get the statistics off of another source which is UNBIASED.

No comment on perl here - but in general, I have found python to be a lot more readable than any of the natural based langauges I have ever tried to read or code in simply BECAUSE of the strict formatting and coding style which in fact only really has ONE rule - that any line ending with a ':' requires the next line at least to be indented with a 'TAB' for it to work correctly.

For (3):
---------

If you are wanting to learn a langauge to use it for something productive like creating useful file convertors and especially for programs with a nice GUI - in fact, for ANYTHING user orientated. I thoughroughly recommend python since it is VERY easy to pick up (I mean it - it took me about 2 days to know almost all of it without even touching a 'users guide' or 'reference manual' but just by reading other peoples source code and trying to modify it to fullfil my own needs) and is also quick, makes nice GUI's and above all, you won't spend ages debugging your code. It is also self documented in almost all places and although lots of people don't realize it, documentation for a specific class or function - in fact, just about anything - can be found by just doing something as simple as:

print(..__doc__)

and a list of functions, variables and classes etc in a module can be found simply with:

print(dir())

If you scour the net for long enough you are almost gauranteed to find a script that provides an interface to browse these listings and documentation strings (I started with one and modified it over time to browse dictionaries and auto create classes dynamically as well as load modules dynamically depending on what was typed in to the browse module input widget).

This also demonstrates pythons power - one of the main reasons for using python above any other langauge is the ability to write very robust dynamic applications with it - so far, I have NEVER coded a single hard limit into ANY of my programs because in all of them, I was able to design simple code that did the same thing dynamically and was only limited by the users hardware or screen resolution etc... (it is also easy to code detection procudures into python scripts and programs so that options which would strain the hardware and/or crash the program are not displayed - e.g. a graphics detection system in a 3D game which stops the user from selecting options that would compromise stability if his hardware doesn't support it).

My advice to you is to go and get some python programs or scripts from somewhere and modify them by copying bits of code and/or looking at how somebody else does something in a different script and then reprogramming it to fullfil your requirements instead.

A good place to start would be a template script which initailizes a GUI and/or data structure(s) for you to extend on!

Having said all that, if you are a website designer and administrator then perl may be a better choice for you - if you like writing freestyle code that only you can understand and use that is - and if you are quite happy to create a new script for every problem you encounter rather than just modifiying old ones to better suit their purposes. As long as you are not writing code for end users but instead for computers to read and parse later automatically without even involving the user then perl is a viable choice. In fact, this is what perl is most useful for - automated scripts that ask few or no questions but that just run and execute providing a result at the end. Anything that involves user interaction however is not so well suited because the user will inevitably introduce errors into your (supposedly) well thought out program execution order and perl is not very good at catching and/or fixing these issues when they arise.

For (4):
---------

What you want to do is basically illeagal and a complete waste of time. If you like breaking into things and testing security, go and get a job as a website security adminisrator or something and put your skills to good use instead of giving yourself a boost by breaking into other peoples websites for fun. If you would like to get a job as a site admin but haven't yet got the skills then go off this forum (which is mainly coders and REAL hackers) and find yourself a crackers site to post questions on. Better still, actually go and speak to a security admin and ask them about cracking. Then you will not only learn HOW it works but will also come to appeciate just how much work goes into keeping websites and the likes secure and perhaps you will realize that maintaining security is just as challenging and as difficult (some would say more so) as destroying it and that persuing security maintenance is in fact, the better option and you even get paid for doing it!...

Addendum:
----------
I spent quite a while typing this and I hope it keeps some people quiet who don't seem to want to live with their differences and also clears up some things as well. If I have offended anybody in any way however, don't bother picking my post apart and blasting it back to me in flaming pieces because I won't reply anyway as I have already spent too much time commenting. Still, for those of you who have been having flame wars over programming langauges, thank you very much, you made my day and you also gave me the incentive to write this after amusing myself by reading through all your very heated comments (some of which are quite funny! ;)

-epat.

THE Comment - Corrections:

epat's picture

The two lines of python code I gave came out a bit wrong because of pesky html trying to understand them - here are re-formatted versions:

print([module name].[class/function name].__doc__)

and:

print(dir([module/class name]))

-epat. :)

Basing a point on which

Anonymous's picture

Basing a point on which language is superior on the quality of code programmers write proves you have a bit more programming to do in life. If you are so proficient in finding bugs in perl applications, why dont you go out and find a bug in amazon.com and have it "crash"...

Basing a point on which

Anonymous's picture

Basing a point on which language is superior on the quality of code programmers write proves you have a bit more programming to do in life. If you are so proficient in finding bugs in perl applications, why dont you go out and find a bug in amazon.com and have it "crash"...

That would be hard since amazon.com isn't in perl, eh?

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix