Addressing pain points is unfamiliar to the Python culture?
In practice, type intransparency is a serious problem – duck typing is only fun as long as everyone a) knows what a duck is and b) agrees on what it should do. Type hints make it a lot easier to work with opaque libraries and inside large codebases.
On the contrary. I use Python professionally since 1997, and it has had all kinds of features added on for different needs, from decorators and generators to async and virtual environments, context managers, list comprehensions, dict comprehensions and what have you.
Of the languages I know of, only C# has had a similar pace of adding new stuff in to the core language (not just libraries).
When did Python shy away from adding new features?
It seems that Python didn't try to please only 2 categories of people: those who dislike significant whitespace, and those who want proper closures.
>and kept a coherent design philosophy that resulted in a clean and simple language
At this point I'd say that Python, with its full feature set, is as complex as a scripting language gets. Maybe Perl 6 trumps it, not sure -- but what you describe is closer to a language like Lua, or tcl or even Go than Python.
Uh, ever seen "Batteries included" referenced in their documentation?
def (str) greeting((str) name):
Edit: it was just an idea, it would be a bit more C-style syntax; of course backwards compatibility wouldn't be possible. Instead of downvoting would you care to explain?1. Instead of being more like C-style function declarations, they look a lot more like C-style type conversions.
2. However closer it may be to C (type before identifier I guess?) it's pretty far from any other mainstream language. For instance, C++ has support for -> syntax for function types (http://stackoverflow.com/questions/22514855/arrow-operator-i...) and some other languages (I can think of Scala) use name: Type declarations.
As a personal preference, I find the python type hinting more familiar than your example, despite (myself) being most familiar with C-like syntax.
Putting the type after the name feels more natural, and the : also translated nicely into 'of type' (or if you prefer for functions 'returns type').
For familiarity, while the C family of languages favors "type name" declarations, the Pascal and ML family of languages use "name: type" instead. So, familiarity is entirely a function of what language you used before.
Second, C-style declarations have their problems, which is why they aren't used much outside of languages that derive from C. Generally, you look up declarations by searching for the name of the variable to determine the type; this generally has less cognitive overhead if the variable is at the start of the clause, not the end, ideally separated by punctuation (note how the "name: type" syntax mirrors Python dictionary "key: value" syntax) [1].
[1] Also, in C/C++ the "type name" syntax complicates the parser, as the parser has to be able to distinguish between type names and other identifiers; while this wouldn't be an issue for Python, there is still no reason to perpetuate this syntax choice.