What are the drawbacks of Python?

This can be a problem in static languages with good type inference, too. When reading code in older static languages like C++, you'll find a bunch of variables and types declared, but powerful and concise languages such as Scala have much less use for intermediate variables, and type inference means that intermediate variables are almost never declared with a type. Field types and method return types often aren't declared either. I don't know if this is a good thing because it forces you to read a lot of code, or if it's a bad thing because it forces you to read many unrelated bits of code when you're trying to get something simple done.

Is it not the case that in Lisp people tend to use values — lists of (probably immutable) data — rather than objects? Objects are in and of themselves their own flavor of custom, specialized language for interacting with a data structure. In Lisp, the language for interacting with lists of lists or what have you is, well, Lisp.

IME duck typing is not a real answer in this situation; that helps when you are programming to an interface in the standard library, or in an API you are using. Otherwise I end up hunting down information about a data type through N layers of method and function calls. Not a good time. :( This actually drove me towards Go as a language with comparable productivity but with a type checker, et al.

I'm not sure where Lisp macros fit into this, if they do. I expect they have a tendency to boil down frequently repeated patterns into something very compact and less error-prone.

As for IDE support, Rob Pike suggested (not in so many words) that if you need an IDE for your programming language, it suggests that something's probably wrong with that language. He's not disputing that people genuinely need them, because yes, jesus h, I really do need Eclipse when you're programming against a reasonably large API. I think I find this line of reasoning more convincing than I would have, say, a year or two ago.

Anyway, for my part, ST2 was enough of a Python IDE for me. And thanks for the tip about Pyflakes, by the way. There's guard[1], which I figured you could rig up with python -c or whatever the flag is to compile. Pyflakes looks easier.

[1]: https://github.com/guard/guard

Exactly. Dynamic typing can provide a temporary fig leaf for bad design in ways where static type checking would be less forgiving. Doesn't make dynamic typing wrong, it just means that bad programmers can get in over their heads more completely and more quickly.

    def demo (n):
        def multiplier (m):
            return n * m
        return multiplier

    x5 = demo(5);
    print x5(4)

    def demo ():
        counter = [0]
        def increment ():
            counter[0] += 1
        def peek ():
            return counter[0]
        return (increment, peek)

    (increment1, peek1) = demo()
    (increment2, peek2) = demo()
    increment1()
    increment1()
    increment2()
    print peek1()
    print peek2()

But, you say, you really want anonymous classes? Well look up metaprogramming then. Python really has quite good support for it. There is no trouble creating anonymous classes on the fly with their own attributes, functions, and so on. They can even inherit from each other. http://www.voidspace.org.uk/python/articles/metaclasses.shtm... might be a good starting place on this for you.

(Note, I do not recommend metaprogramming unless the solution you make will be reused a lot.)

Python stdlib will let you package a C extension. I am not sure why you think the opposite. http://docs.python.org/extending/index.html

> No good isolation tools (virtualenv, the most common tool, silently fails to isolate dependencies when moved)

If you mean it's not relocatable, there's a new option for this http://www.virtualenv.org/en/latest/index.html#making-enviro...

But being not relocatable is not really an issue, as you can simply re-run virtualenv in the new place. All libs you previously installed will work without having to install them again

> Some of the standard library is downright terrible. csv and robotsparser are good examples. This has the side effect of widely-distributing libraries that have subtle but serious drawbacks.

Some stuff in the stdlib are not good that's true, but we have a gigantic library ecosystem at pypi.python.org will very well written piece of libs. Using Python seriously, I have never ever felt the serious drawbacks you are talking about except with tarlib in python 2.4 which was seriously broken.

Not only does it make bindings awkward (and sometimes broken, in different ways depending on the way "scope inference" is implemented) and tends to hide errors (e.g. typo) or generate them much later than possible (even though lexical checking is very cheap to perform at parse time, with explicit scopes), it has pretty much no actual benefit I can think of.

Especially in Python where assignment is a statement, not an expression, so it's not like explicit scoping would prevent putting assignments in place they're currently allowed.

[0] and it's one of the things I find utterly retarded in coffeescript.

I think it would be more accurate to say that if you learn other languages, you'll learn not to hate Python. Python is kind of mediocre in a lot of ways, but it's the only language without any deal breakers.

I find the severe breakages and insanities of Javascript (such as tracking what `this` is) take much more brain-space than Python ever did, personally.

I've been replacing my shell scripts with Haskell scrips lately and the transition is going well. Soon the only two languages I will ever need are Haskell and elisp!

I imagine the order on which you learn is important. I learned OOP with Smalltalk and C++ not only didn't fit in my head, it created an impressive allergic reaction. It took me 8 years to be able to get back to it and finally learn.

And it still feels a horrible kludge.

I learned Python before I had contact with Ruby and I find the irregular syntax hard to parse.

Guido always said he could only afford to break python once but it's not clear to me he'll even get away with once.

So I don't understand your comment about it being a narrow language space.

Which is not just reductionist, but downright silly. C# is not a very good OO language, in the same way Java isn't.

When I want OOP, I play with Smalltalk. Or Self.