>>3
The proponents of Python cite 'indentation' as the worst problem, this is a strawman argument 'this is the worst problem and its not really a problem'. This argument has been voted up presumably by people who like the language, because it is certainly not a good reason not to use Python. I am far from an expert at Python, but I have done a couple of semi-serious projects in the language and will try to recall specifically what I didn't like.
- Broken scoping: Python, like many other scripting languages, does not require variables to be declared, as let (x 123) in Lisp or int x = 123 in C/C++. This means that Python can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data. Local and global scopes are unintuitive. Having variables leak after a for-loop is confusing. Worse, binding of loop indices can be very confusing; e.g. "for a in list: result.append(lambda: fcn(a))" probably won't do what you think it would. Why nonlocal/global/auto-local scope nonsense? Such shortsighted scoping design leads to Python's faulty package system, which exposes everything, so that, for example, typing time.sleep=4 instead of time.sleep(4) would break the system-wide sleep function, while accidentally assigning some method to time.sleep, and you won't even give a runtime error - just a hard to trace bug. Moreover, dynamic scoping impedes encapsulation and compilation, so everything you write will be open source: no FASLs, DLLs or EXEs, while developer may want to have control over the level of access to prevent exposure of internal implementation, as it may contain proprietary code or because strict interface/implementation decomposition is required.
- Inconvenient syntax: FIOC or Forced Indentation of Code (aka "off-side" rule) impedes using CLI, automatically generating Python code and moving around large code blocks. Editing Python code requires special editors (forget about Word/Notepad), that expand tabs into spaces, while transmitting python code through a web post or email breaks indentation. Absence of block-terminator is so utterly confusing, that you'll find yourself ending blocks with #endif anyway. It's painful to deal with other things that need indenting, such as large SQL queries, or HTML when you're using things like mod_python. And why is there ":" when code almost always has a newline after it? Python's whitespace indentation indulges messy horizontal code (> 80 chars per line), where in Lisp one would use "let" to break computaion into manageable pieces: get used to stuff like self.convertId([(name, uidutil.getId(obj)) for name, obj in container.items() if IContainer.isInstance(obj)]), while logical connectives being lost in a pile of other symbols, like "and" in "if y > 0 or new_width > width and new_height > height or x < 0". Instead of usual "fold" and "map" functions, Python uses "set comprehension" syntax, which has a large collection of underlying linguistic and notational conventions, each with it's own variable binding semantics: good luck discerning [f(z) for y in x for z in gen(y) if pred(z)] from [f(z) if pred(z) for z in gen(y) for y in x]. In addition, you will enjoy cryptic expressions like z(*z(*m.i())[::-1]).
- Crippled support for functional programming. Python's lambda is limited to a single expression and doesn't allow conditionals. Python makes a distinction between expressions and statements, and does not automatically return the last expressions, thus crippling lambdas even more. Assignments are not expressions. Most useful high-order functions were deprecated in Python 3.0 and have to be imported from functools. Creating an object just to call a function, like ''.join(map(str, r)), is just annoying sign of bad language design. No continuations or even tail call optimization: "I don't like reading code that was written by someone trying to use tail recursion." --Guido