Python is another of those languages that really annoy the academics in the crowd because it made what is in my mind a very reasonable design trade off. Their goal was to make the language as usable and easy to learn for newbies as possible, while still providing a powerful language that would still allow the intermediate to advanced programmer to implement any computation using an elegant and regular syntax.

In particular, Python is a slightly higher level language than its main competitor, Perl, and is completely Object-Oriented rather than the object and scoping infrastructures being added as an afterthought to the original language design.

Perl hackers will rant about how their language's quirkiness and flexibility make it more powerful than Python, but in point of fact while it's true that Python will not let you stuff an elephant into a purse, only the most lofty gurus would want to anyway.

Lately I've been very happy with Ruby - it does all of what Python does and eliminates the mandatory indentation issues. Ruby is a more purely object oriented language than Python as everything is an object, even the primitive types.

That having been said Python still gets a place of honor in my tool belt and that's unlikely to change in the foreseeable future.

Thus far, people have failed to mention some of Python's best features: a vast library of modules providing everything from math functions and string manipulation to common internet protocols and a GUI or two, an online library reference guide, and an online tutorial. Learn python now at www.python.org.

Oh, and nobody mentioned that it's named for Monty Python, not a snake.

I originally learned Python because it was easy to learn, in particular, in comparison with Perl, and because a friend encouraged me to. I continue to use Python because, for many of the things I need to do, it is simply the quickest way to get the job done.

Python also allows for overriding of functions and variables at multiple levels (local, instance, class, superclass...) dynamically. This makes Python a great glue language as well as a dynamic object language like LPC used in MUDs.

In general, folks who hate Python despise the whitespace thing, but once you get over it, you realize it does make it infinitely easier to read other people's code. There have been several suggestions to imitate braced block structures on the Python site.

I use Python for everything except when I need to do a lot of string-munging or I need to run the script/program as setuid root (for which Perl is the ultimate programming language). The Perl interpreter will allow the script to run as the root user, where the Python interpreter won't. In order to build Python scripts to run as root for every user, you have to build a shim in some other language (such as C) that does the switch to root and then calls the Python script. Also, writing Python extensions is a pain in the ass.

Although the python language has many good features, here are a few bad features that I have encountered.

There is no requirement to declare variables, so it is possible to mistype the name of a variable and inadvertantly create a new one or try and refer to a non-existant one. This leads to bugs that are hard to find, especially as much checking is deferred until run-time and only happens if that code is executed.

The white space indentation scheme works for small code segments and a few levels of indentation, but for large blocks of code and lots of nested blocks it can be hard to keep track. Of course functions should be used, but see the next issue.

There is a high execution time overhead for calling functions. Various articles have been written to explain how to write faster python code, but the sad fact is that often the best speed up is to move a function body into the body of a loop. This exacerbates the previous issue and, even then, python is not suited to computationally intensive tasks.

from Linux Journal, with permission

Why Python?

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

by Eric S. Raymond

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.tuxedo.org/~esr/sng/. I have also written implementations of several odd general-purpose languages on my Retrocomputing Museum page, http://www.tuxedo.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 http://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 1for 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.

This is the genealogy of the programming language Python:

Python is a child of ABC, Modula 3 and C.
Python was first known as Python in year 1991.
Then it begat Ruby in year 1993.
It became Python 1.5.2 in year 1999.
It became Python 1.6 in year 2000.
It became Python 2.0 in year 2000.
It became Python 2.1 in year 2001.
It became Python 2.2 in year 2001.
It became Python 2.3 in year 2003.

This genealogy is brought to you by the Programming Languages Genealogy Project. Please send comments to thbz.

Python vs. Java: Readability

This node will address only one area of comparison between programming languages: readability. Do not, however, think that this sort of comparison is superficial and not valuable. Some estimates put code maintenence at almost fifty percent of total cost in a development project. Going back to code you wrote months ago, it can often be quite difficult to remember what's going on in your program. This is especially true if the code was written by another person. While good comments will always help, the truth remains: ugly code is hard to work with.

Readability is an area in which Python excels. To help give you an idea of this, I've written several short programming exercises in both Java and Python. Now, to be fair, I'm not really comparing apples to apples here. Java is certainly the more powerful language, and one would expect it to be more complex. However, Java's syntax and formatting is similar to that of C and C++. I would eventually like to flesh this node out with examples comparing Python to Perl, but alas, my ability with Perl is not sufficient at this time. Until then, I give you the samples below:


Console Test:

Java:
public class ConsoleTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000000; i++) {
            System.out.println(i);
        }
    }
}

Python:

for x in xrange(1000000):
    print x



Hash Test:

Java:
import java.util.Hashtable;

public class HashTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++ ) {
            Hashtable x = new Hashtable();
            for (int j = 0; j < 1000; j++) {
                x.put(new Integer(i), new Integer(j));
                x.get(new Integer(i));
            }
        }
    }
}

Python:

for i in xrange(1000):
    x={}
    for j in xrange(1000):
        x[j]=i
        x[j]



List Test:

Java:
import java.util.Vector;

public class ListTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            Vector v = new Vector();
            v.addElement("a");
            v.addElement("b");
            v.addElement("c");
            v.addElement("d");
            v.addElement("e");
            v.addElement("f");
            v.addElement("g");
            for (int j = 0; j < 1000; j++) {
                v.addElement(new Integer(j));
                v.elementAt(j);
            }
        }
    }
}

Python:

for i in xrange(1000):
    v=['a','b','c','d','e','f','g']
    for j in xrange(1000):
        v.append(j)
        v[j]



IO Test:

Java:
import java.io.*;

public class IOTest
{
    public static void main(String[] args) {
        try {
            File f = new File("scratch");
            PrintWriter ps = new PrintWriter(new OutputStreamWriter
                                             (new FileOutputStream(f)));
            for (int i = 0; i < 1000000; i++) {
                ps.print(String.valueOf(i));
            }
            ps.close();
        }
        catch(IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

Python:

f=open('scratch','wb')
for i in xrange(1000000):
    f.write(str(i))
f.close()
push = P = quad

Python /pi:'thon/

In the words of its author, "the other scripting language" (other than Perl, that is). Python's design is notably clean, elegant, and well thought through; it tends to attract the sort of programmers who find Perl grubby and exiguous. Python's relationship with Perl is rather like the BSD community's relationship to Linux - it's the smaller party in a (usually friendly) rivalry, but the average quality of its developers is generally conceded to be rather higher than in the larger community it competes with. There's a Python resource page at http://www.python.org. See also Guido.

--The Jargon File version 4.3.1, ed. ESR, autonoded by rescdsk.

Some people still have the illusion that Python is just a "toy-language" just because it was designed to be syntactically clear and easy to learn. Although it might have been true before, I don't feel that today's Python has had to make any compromises that limit its power of expression. Unlike many other modern languages, Python has garbage collection, lexical scoping, simple generators, iterators and several tools for functional programming such as list comprehensions and lambda functions. Also, you should not forget Jython (former JPython) that allows Python and Java interoperate seamlessly and produces Java class files from Python source.

Beauty is in the eye of the beholder, but for me, Python has the most beautiful syntax I've seen in any programming language. Although many experienced programmers dislike Python's lack of block delimiters, it removes unnecessary clutter from the source code. Using, for example, the C-like {...} brackets makes it easier to write a parser, I claim that the human eye instinctively sees the indentation first and foremost. How many programmers have been bitten by the following piece of code?


if (a < b)
    b = 0;
    ++a;

By making indentation part of the syntax ensures that what you see is always what you get.

It all has a price, though. Especially after the addition of real garbage collector, Python programs run considerably slower than an equivalent program in C or even other interpreted languages such as Perl or Java. For most tasks, however, increased programming productivity makes up for the lack of program efficiency.

What I'm ultimately trying to say is that Python makes an excellent first language for someone who has never programmed before, but at the same time it is a powerful tool for professionals looking for a good generic language.

Python is a term used to refer to one of the main collaborators on the BBC sketch show Monty Python's Flying Circus.

The original pythons were Terry Gilliam, Terry Jones, John Cleese, Eric Idle, Graham Chapman and Michael Palin.

Often used in the context of "the n surviving Pythons", since one of them is dead and the rest will inevitably follow. When n=0, we will have lost the last of a unique group of comedians who changed the face of British comedy.

Python can also be used as an abbreviated form of the name Monty Python's Flying Circus

The Python node, perhaps more than any other, speaks volumes about the readership of E2:

IT`S A FUCKING SNAKE, IS IT NOT?

``trust in meeeee, trust in me''

Native to India, Africa and Asia, the Python is a constrictor; not venomous, it literally squeezes the life from its prey before swallowing it whole. As such, it plays a valuable role in its ecosystem by policing the population of rodents, insects and other pests.

Despite its fearsome reputation, the Python is endangered due to the taste of the western world for shoes and wallets made from its skin, of which it can produce a huge amount (a Python, the world`s largest snake, can grow up to ten metres long). In its natural environment, the Python may live for twenty years.

The Python uses its extraordinary killing technique sparingly. Interestingly, despite the strength easily to kill a large mammal combined with the benefit of camouflage, its instinctive response when challenged is to retreat rather than risk itself in fight.

Although the Python prefers the dense rainforest as a home, its ability to crawl, climb and swim make it adaptable to a range of environments. Pythons have been reported as a problem in large cities. Unsurprisingly, it makes a controversial pet.

The female Python is unusual among reptiles in that she incubates her young as would a chicken.

In some cultures, also a euphemism for `penis' in the context `purple headed power python'.


UPDATE: It has been pointed out (by Razhumikin) that the wording of the above comments may lead people to believe the Python to be a species of snake. This is not, in fact, the case. The term ``python'' refers to a family of species, or genus.

enkidu dwells on the matter further by adding:

In your clarifying statement, you should probably not refer to a genus as a ``family of species'', given that there is also a class called ``family'' which is a family of genuses. But I'm doing it too, since there's also a class called class, which is a family of orders...
Following on matthewb's write-up the pythons are most often considered to be the members of the genus Python, in the sub-family Pythoninae (which is, itself, nested in the boa family Boidae). Other members of this sub-family, who are taxonomically speaking pythons as well, are the genera Aspidites, Antaresia, Apodora, Bothrochilus, Calabria, Leiopython, Liasis, Loxocemus and Morelia.

General information

Pythons are heavy-bodied constrictors, meaning they rely on their size and strength to capture and kill prey by crushing. All python species are non-venomous. They are for the most part terrestrial, and of brown, black or green colour (for camouflage). A notable exception is the green tree python (Morelia viridis), which is considerably more slender than it's con-generics, arboreal and of a truly striking green colour.

The Burmese (Python molurus) and Reticulated pythons (P. reticulatus) are truly gigantic snakes, measuring up to 32 feet in length and weighing more than 300 pounds. They are not, however, the largest snakes on the planet. That honour falls to the Anaconda (which is a member of the boa sub-family, Boinae), which has been measured at 37 feet in length and must have weighed well over 500 pounds (Anacondas are considerably more robust than pythons). Despite their large sizes, these two species are often kept in captivity quite successfully, given their relaxed temperament and the fact that they only feed two to four times per year.

Not all python species are as large as these giants, however. The Anthill python (Antaresia perthensis) remains under two feet in total length as an adult, and the common Ball python rarely exceeds four feet in length. This latter species is very often kept as a pet, and is particularly well known for its docile character and tendancy to curl into a ball when held (thus the name).

Some pythons, like the Reticulated, display unusual reproductive behaviour for snakes. While other oviparous snakes lay their eggs and then depart, the female of this species will remain on her nest, without eating, to protect the eggs from predators during incubation. Some have hypothesized that this is due to the slow growth rate of the species and their low lifetime reproductive output. By remaining on the nest, a female Reticulated python, which will only have a couple of clutches in her lifetime, increases the odds that one of her offspring survive to reproductive age (biologists call this her fitness).

Finally, it should be noted that the wonderful and horrific stories often heard about savage, human killing snakes are urban myths and have little basis in reality. I say little basis because there are documented cases of pythons attacking humans, but in suburbia rather than the jungle. Almost all attacks can be considered due to poor husbandry or frightful stupidity on the part of the Homo sp. rather than the Python sp. And, if you ever see a picture of a boy ingested by a python circulating on the internet, know that it is a fake.

Taxonomic information

The genera Antaresia, Apodora, Aspidites, Bothrochilus, Leiopython, Liasis and Morelia are restricted to Australia, New Guinea and Indonesia, while the genera Calabria, Python, are found in Africa and Asia. The monospecific genus Loxocemus is native to Mexico, and is only tentatively placed in the Pythoninae.

Species list1

  • Genus Anataresia, the children's python2:
    • A. childreni, Children's python
    • A. maculosa, Spotted python
    • A. perthensis, Anthill python
    • A. stimsoni, Stimson's python
  • Genus Apodora:
    • A. papuanus, Papuan python
  • Genus Aspidites
    • A. melanocephalus, Black-headed python
    • A. ramsayi, Woma
  • Genus Bothrochilus:
    • B. boa, Bismarck ringed python
  • Genus Calabria:
    • C. reinhardtii, West-African burrowing python
  • Genus Leiopython
    • L. albertisii, White-lipped python
  • Genus Liasis, the water pythons:
    • L. fuscus, Brown water python
    • L. mackloti, Macklot's python
    • L. olivaceous, Olive python
    • L. sawuensis, Sawu python
  • Genus Loxocemus:
    • L. bicolor, New world python
  • Genus Morelia
    • M. amethystina, Scrub python
    • M. boeleni, Boelen's python
    • M. Bredli, Centralian python
    • M. carinata, Rough-scaled python
    • M. clastolepis
    • M. kinghorni, Australian scrub python
    • M. nauta
    • M. oenpelliensis, Rock python
    • M. spilota, Carpet python
    • M. tracyae
    • M. viridis, Green tree python
  • Genus Python
    • P. anchietae, Angolan python
    • P. curtus, Blood python
    • P. molurus, Burmese python
    • P. natalensis, South African rock python
    • P. regius, Royal, or Ball, python
    • P. reticulatus, Reticulated python
    • P. sebae, Central African rock python
    • P. timorensis, Timor python
1I haven't tried to list the sub-species here, given both the taxononmic uncertainty in these classifications and the sheer number of variations.
2Formerly considered part of the Liasis genus.

Some resources:
* http://www.nafcon.dircon.co.uk/pythons_python.htm
* http://www.omne-vivum.com/c/20154.htm
* http://www1.embl-heidelberg.de/~uetz/families/Boidae.html

Python

Family of snakes (suborder serpentes), that are amongst hobbyists generaly appreciated for their calm and docile nature. The group is closely related to boas and anacondas and together these three groups are known as snakes of the old world.

Contrary to common belief these three groups (pythons, boas and anacondas) do not represent the (evolutionary) oldest groups of snakes, that would be the Typhlopidae or "Blind Snakes"

The whole group is non-venomous, killing its prey by constriction. This type of constriction does not mean that they choke their prey to death by closing of their trachea or windpipe. It means that the snake throws a loop (or a number of loops, depending on the size of the prey, relative to the snake) of its body around the chest of its prey, and slowly tightens this loop. Thus making it impossible for the prey to inhale. This of course results in the death of the prey, after which the loop of the snake which is wound around the prey's body is tightend once more, to break the preys ribs in order to be able to swallow it easier.

The largest snake in the world (in length, not weight) is a Reticulated Python (see this) which can get up to about 10 meters long (which is longer than a dubbeldecker bus!), altough other species (such as the Anthill Python (Antharesia perthensis)) stay very small (adults grow to about 60 cm). The heaviest snake in the world, by the way, is an Anaconda (Eunectes murinus) which can weigh over 250 kilos, and is unable to support its own weight on dry land (This is not a member of the Pythonidea Family thought).

At the time of this publication, nine writeups in this node pertain to the programming language, three pertain to the genus of non-fictional snakes, one is a dictionary entry, and one pertains to the performers in Monty Python's Flying Circus.

This node is missing a critical piece of literature, namely the very origin of the word "Python!"

Ovid, Hyginus, Robert Graves, Erwin Rohde, and Karl Kerenyi have all written extensively about the creature and the myths associated with him, but the earliest known mention of the dragon-like beast Python is in the Homeric Hymn to Apollo (which Homer probably did not write).

According to the story, a serpentine monster named Python was terrorizing all of Greece, in pursuit of Leto, a lesser goddess of the dark night sky. Python was a hideous creature whose body was so vast that it could flatten entire acres of cities and fields. Its bite, breath, and presence were poisonous, radiating an evil miasma into the areas around it. The reason for its violence was that Hera was wrathful toward Leto for laying with Zeus, and Hera dictated that Leto would not be allowed to give birth to her twins (Artemis and Apollo) anywhere that the sun shines. Python pursued everywhere that Leto fled, and many smaller islands actually "swam away" from Leto's efforts to escape to them: the islands both feared the monster's carnage and destruction, and Hera's anger.

Leto finally found herself on the shore of the island Delos, and Delos did not initially flee her or turn her away, because it considered itself far too inhospitable for her to consider it a place of refuge: its terrain is forbidding to all agriculture, it lacks any real mineral resources, and its only real claim to fame at the time was a small temple to Zeus on one of its conical hills. For this very reason, Leto heaped flattery and promises on the island, swearing,

Delos, if you would be willing to be the abode of my son Phoebus Apollo and make him a rich temple –; for no other will touch you, as you will find: and I think you will never be rich in oxen and sheep, nor bear vintage nor yet produce plants abundantly. But if you have the temple of far-shooting Apollo, all men will bring you hecatombs and gather here, and incessant savour of rich sacrifice will always arise, and you will feed those who dwell in you from the hand of strangers; for truly your own soil is not rich.
—Homeric Hymn to Delian Apollo 51–60

The island accepted Leto's pleas and allowed her to shelter in its crags and caves, well out of the sunlight, so that she could finally deliver her children.

Years after this event, when Phoebus, the Greek solar deity, was still young and wanted to make a proud name for himself, he took up his golden bow and arrows and set out to slay the serpent, intending to avenge the grief it gave to his mother. Python fled Apollo's pursuit, making a line of destruction all the way to the Greek town of Delphi, on the southwestern portion of Mount Parnassus in the Phocis valley. At Delphi, Python hid himself beneath or behind the temple where the Earth-goddess Gaia kept her prophetic oracle. Normally, this would be a clever way for the serpent to take refuge, both because Python himself was sacred to Gaia (in some versions, Python was considered the hero and protector of all of Mount Parnassus), and because the temple space was considered wholly inviolable, even by other gods.

Apollo followed Python all the way to the innermost sanctuary of the temple, where the Delphic Oracle sat on her tripod beside a cleft in the mountainside, where volcanic fumes emerged to give her visions of prophecy from Gaia. He killed Python there in the temple, a dreadful crime against Gaia and her oracle. Apollo placed the Omphalos Stone, a massive boulder considered to be "the navel of the world," on the dead serpent's head, to make sure it was dead, and the rest of its corpse was left hanging out the front of the temple, rotting with dreadful odor in the intense sunlight. The town was given the secondary name Pytho, "rotting," as a result, and the oracle (who retained her status and job at the temple) was titled the Pythia, for the place name. Apollo re-appropriated the temple into his own service instead of Gaia's, and as a penance for the offense against Gaia, Apollo instituted the Pythian Games, over which he personally presided.

Some versions of the story depict two serpents instead of one- a female named Delphyne and a male named Typhon; some depict Python in Apollo's service protecting the Omphalos instead of buried under it.


The symbolism of the story has been widely debated: the monster's miasma could be related to plagues or to toxic fumes from sulfurous vents and hot springs near and beneath the temple of the Delphic oracle. Another interpretation is that Apollo's slaying of Python represents how sunlight banishes the mists which form over swampy areas overnight, and how nocturnal frogs and swamp animals retreat into hiding during the day.

The story of Saint George and the Dragon is considered to be generically the same tale type, or a related type, to the story of Python (Aarne-Thompson Index tale type 300, "The dragon slayer").

Py"thon (?), n. [NL., fr. L. Python the serpent slain near Delphi by Apollo, Gr. .]

1. Zool.

Any species of very large snakes of the genus Python, and allied genera, of the family Pythonidae. They are nearly allied to the boas. Called also rock snake.

⇒ The pythons have small pelvic bones, or anal spurs, two rows of subcaudal scales, and pitted labials. They are found in Africa, Asia, and the East Indies.

2.

A diviner by spirits.

"[Manasses] observed omens, and appointed pythons." 4 Kings xxi. 6 (Douay version).

 

© Webster 1913.

Log in or register to write something here or to contact authors.