They think it's great because, in a tragic case of hilarity, jumping into code with minimal design is what python is great at.
We think it's great because, among other things, it has first-class functions and a very high code:boilerplate ratio. This lets us write very concise, readable, and maintainable code.
That's the tragic case of hilarity I was talking about. You do realise that you're talking about a language that takes the law of least astonishment and throws it out the window? There are too many exceptions to the rule in Python, leaving most people writing things that fail and silently corrupt data, or fail and displays an incomprehensible message to the user. There are too many leaky abstractions, too many unexpected surprises, too many exceptions to the rule. All those things are bad, and python has them all in spades.
Eww, no. I've never seen good Python code that asserts types because it's not the idiom for you to care. For instance, suppose you write a function like:
def get_contents_of(obj): return obj.read()
In this case, obj might be a file, or a web request, or a string (via the StringIO interface). Who knows? Who cares?
def foo (a, b) :
return a/b * 100;
Python gives you that check for free when you try to call the method. Let it do the heavy lifting and concentrate on the parts of the problem you actually care about.
Well, except that it is you, the programmer, who is doing the heavy lifting. You have to make sure everything is specified, the language won't help you.
Exceptions are one of the worst things to have become common - an "error" is almost always only caught outside the scope that it occurred in, hence the stack has already been unwound and thus there is no sane way to fix the error and retry the operation that caused the exception.
Yeah, that would be terrible. You almost never use them in Python like that,
Okay, then how doyou use them? Show me one way for a library function to throw an exception for a reason that is fixed by the caller so that the library can retry the line that threw the exception?
I think it boils down to you not knowing idiomatic Python.
Unfortunately I've had to do lots of work in python over the years, both maintaining others' code and writing new code. The reason I know all these nasty-will-bite-you things is because I've run into them in various different programmers code, in various different companies. The problem with python is it's easy to pick up in a few minutes, but all those exceptions to the rule makes it hard to even guess what something might do at runtime. The most frequent problem I've seen is the insane way scope changes in a single line of code when a read of a variable is changed to a write of the same variable.
Changing "var_b = var_a" into "var_a = var_b" should not change the scope of either variable, but in python it does, and it is considered "pythonic". Other languages consider such a thing to be madness, but in python it is considered to be idiomatic rather than just idiotic.
That's OK. I'm ignorant about lots of things, too. But I think you'd find that you enjoy it more if you stop trying to write C or Java in Python, because that almost never works out well.
The problem with python is the same one that PHP has - it developed, not from careful design of well-understood and researched principles, but from the desire to get a language that appears simple. They've succeeded - it certainly appears simple, until you have to maintain it. Just for comparison, the grammar for python (a "simple" language) is roughly twice as large as the grammar for C (a "difficult" language). That's twice as many keywords, special symbols, operators, etc to remember, without even starting to remember the library functions, nor taking into account all the little 'gotchas' that resulted from little-to-no upfront design.