As I pointed out in his comments section, I'm thinking the author needs to try out Ruby.

I would say that python isn't a perfect tool for tackling large problems on their own, but for largely different reasons.

You'll notice that Ruby implements objects in a very nontraditional OO way, seemingly similar to python on some levels. But typical OO restrictions create anti-patterns (excuse me, 'design' patterns), instead of direct access or on the fly coding.

The consenting adult argument is compelling for nontraditional semi-encapsulated object implementations, and simply requires a different type of programmer or team to do successfully.

I've been spoon-fed OO since 13 (C++/Java) but am now seeing the good in taking away the boilerplate. Just as OO replaced procedural and (Temporarily) functional paradigms, we will see hybrid languages replacing traditional OO as time comes along (Ruby seems to be a mix of OO, functional, and imperative).

I've had all these same complaints about Python, and this summarizes them quite eloquently.

Python sorta kinds tries to be half way include objects and functional programming, but not really. I especially agree that having to type "self." for every single member instance reference anywhere in your program is just as annoying as much of the boiler plate Java requires. I tried using objects in Python for a while, but found that it just made things more verbose than writing procedurally.

"However, these libraries are inherently static. This means that 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."

Ermmm.... I think someone misinformed him. In Python, not only can you use the standard library, but you can also use third party libraries as well. And Python's got a ton of those.

Personally, I think the author can make a case that he doesn't like python, but I don't see anything here that makes Python bad. Different strokes for different folks.

The first 2 maybe... the rest though are pretty nitpicky. Surely there are more important criteria for selecting a language than minor syntax issues.

I never got the argument about one-line lambdas... Every time I needed a lambda, it was either one line, or deserved a new function (even if nested). Are there some serious cases where it's not enough?

    def x(bar, fram):
        z = foo(bar, fram)
        baz(z)

    button.onClick(x)

    button.onClick(
        def (bar, fram):
            z = foo(bar, fram)
            baz(z)
    )

  button.onClick(lambda bar, fram: baz(foo(bar, fram)))

    class Somebutton(Button):
        def onClick(self):
            .....
        def onSomethingElse(self):
            .....

I also feel that doing OO python is a pain.

I have had fun scripting with it however.

Just to correct one point from that post: you can close the list of members of a class using __slots__ http://docs.python.org/reference/datamodel.html#slots

I really like the "Classes in Python are more like dictionary objects with functions attached than classes." part though. It's exactly what I expect from objects. There aren't that many situations when we need anything more.

Someone doesn't like something. News at 11.

    function gencycle() {
        var args = Array.prototype.slice.apply(arguments),
            i = 0;
    
        return function cycle() {
            i = (i+1) % args.length;
            return args[i];
        }
    }

    class GenCycle(object):
        def __init__(self, *args):
            super(GenCycle, self).__init__()
            self.args = args
            self.i = 0
        
        def __call__(self):
            self.i = (self.i+1) % len(self.args)
            return self.args[self.i]
        

    >>> from itertools import cycle
    >>> iter = cycle(['red', 'green', 'blue'])
    >>> iter.next()
    'red'
    >>> iter.next()
    'green'
    >>> iter.next()
    'blue'
    >>> iter.next()
    'red'

  def cycle(*args):
    i = 0
    while True:
        i = (i + 1) % len (args)
        yield args[i]

  for arg in cycle("red", "green", "blue"):
    print (arg)

  gencycle = lambda *args: cycle(*args).next

  get_next = gencycle("red", "green", "blue")
  print (get_next())
  print (get_next())
  print (get_next())

I am quite unimpressed by these arguments. This blog post is a joke filled with inaccuracies.

- Encapsulation. Encapsulation in every language such as Java and Python is by convention. There are always ways to break it. Even in C++. Somehow the blogger missed out on learning "__" notation.

- Batteries. Nearly all the Python libraries are pure Python files which you can edit or debug. You can even debug the C modules with a C debugger if you like since they are just dynamic/shared libraries. You can delete libraries that you never use from your installation.

- This. This is probably the only legitimate complaint, but it all boils down to syntactical sugar.

- Members. Another blatant lack of knowledge. It is possible to enforce static members with the "__slots__" metamember. You can override the default object behavior by implementing the "__getattribute__" and "__setattribute__" members to suit this blogger's preferences.

- Lambda. Another syntactical sugar complaint. Python functions are first class variables.

Conclusion: The blogger's failed attempt to bash Python reveals his own lack of knowledge about the language.

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

  def foo(self, x):
    self.bar(x, 42)

  class MyClass:
    def bar(self, x, y):
        print ("%s %s" % (x, y))

  MyClass.foo = foo