The article's a few sentences of useful text, wrapped in heaping mounds of "clever" storytelling. Here's the meat of it, with comments:

  The first bits of Python all point to this: the purpose of python is to have a language like c or Perl but to make it easy to read, easy to use, and short. The short part almost overrode everything else. This was your objective, your mandate from heaven.

Python is readable and expressive, not short. If you want short, use Perl, J, or APL. Many aspects of Python's syntax and semantics are quite verbose, in the interest of making the resulting code easier to read.

  There is no encapsulation. There are three tiers to OO. One of them is encapsulation. Having OO without encapsulation is [useless].

Python does have encapsulation. Attributes are named according to their exposure: non-public attributes are prefixed with "_", and internal with "__". There's even a (hack-ish) name mangler, which prevents clients from accidentally depending on internal attributes.

Note the word "accidental". In a language such as Python, there is no way to completely prevent clients from accessing internal state. Even C++ or Java allow sufficiently knowledgeable / desperate clients to poke around wherever they like. Python's philosophy is that since clients will access internal state anyway, it's best to have a sane, documented mechanism.

  As the saying goes, "Batteries are included," but as the saying fails to tell you, try to change your batteries and you are completely screwed. [...] if the library doesn't do what you want it to, you are screwed. There is no diagnosing or fixing errors in the library. If they happen, pack up and try a different language.

This reads like he believes the standard library is the only library, which (considering he uses C++ and Java) is a truly bizarre belief. If he doesn't like the standard HTTP library, it's trivial to either distribute a modified version, or use somebody else's (eg, libcurl). Many large Python projects distribute variants of standard library modules to work around errors or missing features in legacy versions of Python.

  And then you omitted the implied this. [...] [Python] doesn't really take care of anything for you. You have to have "this" as the first argument to every function in a class. Once in a function, you have to use "this" to access any variables or other functions.

The problem with an implicit "self", aside from it violating the Python Zen, is that it makes a number of cases nastily ambiguous. For example, consider the following method:

  class Foo:
    def something():
        a = True
        b = False

In this code, the only way to know the scope of 'a' and 'b' is to read the entire class definition. Using explicit scoping prevents ambiguity.

Another advantage, though much less, is that it discourages excessive numbers of attributes. Somebody coming from a Java background probably likes having a few hundred attributes floating around in various states as his objects run, but I hate having to deal with code that has so many "moving parts". Adding a "tax" of five characters per attribute access/modification makes code much easier to read and debug.

  To add insult to injury, python has no explicit support for member definition. A class's members are created by setting them equal to something. There is no way to explicitly define them in the class definition. Anybody, anywhere, can add (or remove) members variables from a given object.

There are many ways to define members in a class definition. The most heavy-handed is the "__slots__" mechanism, but you can also use properties or simple "foo = None" statements depending on the level of control clients should be allowed.

If the author doubts that Python can restrict attribute modification, he should try assigning to a tuple's attributes.

  Classes in Python are more like dictionary objects with functions attached than classes.

Not "more like", are. Python classes and objects are (in most cases) dictionaries.

  [Lambdas] can only be one line. Ok, what is the point of including lambdas at all if they can only be one line? I mean, sure, I can pass an incrementor as a function reference, but real functional programmers don't use lambda's this way (well they do, but that's just the most basic use). Including the feature at all is an insult to those who would try to use it.

This is completely wrong. I've stated this in another comment, but Python's lambdas may be of arbitrary size. Lambdas may only contain a single expression, but (as any LISP or Haskell programmer can tell you), this is not a substantial drawback. If you'd like to pass multiple statements, just define a procedure! That's why they exist!