You seem to be very well acquainted with proggit indeed as this kind of pre-whining is quite common there. Though the little twist about it at the end is a new (and quite despicable) addition to it.

> it seems to me that this just adds to the list of Python issues

Considering this page is at least two years old, it's older than e.g. most of the GIL hubbub.

> The ongoing saga with the GIL (although I realize this has advantages in simplifying C extension development)

The GIL saga makes the whole language simpler (running directly opposite your thesis that all these "points" make the language more complex), though it does make taking advantage of multiple cores harder (if you somehow have a beef against multiple processes).

> String formatting changing seemingly from 2.4 and every version thereafter

You might want to read and test things before that kind of claims. When the article you link says:

> In Python 2.5 and later, there's a new formatter

it means the old one is still there. It was not removed in Python 2.5 (or later, `"It is %s!" % foo` still works perfectly in Python 3.1). The second "point" of your article is hellishly disingenuous as it has nothing to do with formatting. It's also a pretty terrible article as it uses "long form" formatting in the `format` calls (which are used to make bindings clearer, whereas you can use C#-style positional formatting if your strings are short and readable in and of themselves)… and then whines that the formatting calls are too verbose.

And of course, coming from Perl the article you link to suggests… implicitly pulling variables out of the context instead of explicitly sending them to formatting.

> The 2.x/3.x split (yes I know there are reasons)

Indeed, and a number of these reasons center around making the language simpler and more consistent (`print` as a function, reorganization of the stdlib, ...).

> Version issues for scripting [2]

This has nothing to do with Python as a language.

> Syntax inconsistency. I know this one will be controversial but I'm referring to things like the fact that del() is a operation

What are you talking about? What is `del()`? Are you talking about `del` as in `del foo` and expressing your dislike of it being a statement? Considering the original job of `del` (completely remove a binding from a scope), I'm not sure what else it could have been (though I can't say I like it much, be it to remove a binding from a scope or remove elements from structures). I'd also enjoy your explanation of how it demonstrates inconsistency: which other Python non-statement operation is able to destructively alter scopes? And is a majority of the scope-altering operation non-statements? If it is not, would not the non-statement scope-altering operations be inconsistent?

> Other issues [3]

Few of these are universally valid. In fact, I can find none that is apart from whitespace making it harder (if not impossible) to generate code[0]. Some of these complaints are plain nonsensical (Python being an "untyped language"), most others are personal preferences which you may or may not agree with (Python's scope confusion and crappy lambdas — or more precisely overuse of statements as Haskell's lambdas have exactly the same limitation — bug me a log, while TFAA's dislike of `eval` basically amounts to "I hate languages where not everything is decided at compile time)

> Isn't something like Ruby or Lua a lot cleaner in this regard?

Ruby definitely is not, though the choices it made are most definitely different. I don't know enough Lua to comment on it.

But if you want orthogonal and consistent languages, you probably should not look at even remotely popular languages anyway: they're mostly hobbled together. Even Haskell, which your [3] seems to hold as some kind of holy grail, is a complex and not necessarily consistent language. Consistent languages are generally very small (syntax-wise, as every syntactic construct you add to the language exponentially increases your chances of breaking syntactic consistency) and provide lots of power to users (e.g. the ability to very easily define control-flow structures, increasing the risk of lowering the "external" consistency of produced code). Examples of such languages are Smalltalk, Forth, Lisp (especially, in my opinion, the Lisp-1 family). Though really all of those should be pluralized as they pretty systematically ended up forking from a common ancestor into a multitude of related-but-incompatible (usually library-wise, sometimes syntax-wise or semantics-wise) languages.

[0] but then again, how often does that happen, and doesn't Python provide the tools to generate a running system rather than have to statically generate code which will then have to be compiled and run? I can't say I've often liked this kind code generation, which in my experience has more often lead to pain and suffering than enjoyment, e.g. in GUI toolkits)