I think while the experienced here might scoff at it, it still remains one of the most accessible and -fun- languages. Also I just adore iterators and any language without it is a no-go.
> I think while the experienced here might scoff at it, it still remains one of the most accessible and -fun- languages.
This is a shit attitude, and this comes from someone who mostly does C++ and Java at work, you know, "real languages" with braces and builds and whatnot. Python being easy and accessible isn't a bug, it's a goddamn feature.
I'm not sure dynamic typing is the fault by itself, I guess it's from a lack of compilation phase, as other languages such as Elixir seems to protect you from typing mistakes much more than Python does. My running theory is that dynamic typing is a sprectrum, and Python is on the side of "it's very easy to get it wrong" compared to other languages. I haven't used the recent versions with type hints, so it might've gotten better.
Also, I'm not a fan of how it feels. It is afraid of functional constructs: come on, itertools.accumulate is a simple reduce summing the elements. Why is Python so against map, reduce and ergonomic lambdas?
Like Go, it seems Python wants to be simple enough to be understood in large teams of varying developer skills, but unlike Go, Python is much harder to understand and debug in hairier codebases when you add metaclasses, weird backward compatible behaviours, monkey patching, typing woes and an often substandard stdlib.
I don't think this is true at all. There have been people against dynamic typing since it was first introduced, and their justifications haven't changed due to Python. There's nothing about Python's approach to dynamic types that is particularly egregious, in my opinion. In fact, since type annotations were added to the syntax in 3.6 (I think), there is now support for external tools to do some static type-checking (though these are not enforced by the language proper). If I were to point to an in-use dynamically typed language with dynamic type problems, I'd be pointing at JavaScript. The extend of implicit conversions is truly heinous (again, just my opinion).
> I'm not sure dynamic typing is the fault by itself, I guess it's from a lack of compilation phase
I'm not sure I understand this. For a language to be "dynamically typed", it must necessarily not check types during compilation no matter what, otherwise it would be "statically typed". So I don't see how adding a distinct compilation phase to Python's evaluation model would affect anything.
Also, Python does have a compilation phase; it just isn't distinct from the interpretation phase. There are no longer interpreters separate from compilers, as far as mainstream languages are concerned.
> Why is Python so against map, reduce and ergonomic lambdas?
The actual answer to this is that Guido van Rossum didn't want to make them first-class. That's the whole justification.
> Python is much harder to understand and debug in hairier codebases when you add metaclasses, weird backward compatible behaviours, monkey patching, typing woes and an often substandard stdlib.
Most of these sound like problems with dynamic types, honestly.
I'm pretty sure that honor falls upon PHP and perhaps Perl as well as JS.
> Python is much harder to understand and debug in hairier codebases when you add metaclasses, weird backward compatible behaviours, monkey patching, typing woes and an often substandard stdlib.
Indeed, Python (it's not just about dynamic typing, but more about how the underlying constructs of the language are exposed as first class citizen) makes it possible to write very bad programs, that no one would want to work with.
But this is also what allowed to build great libraries, that could abstract a lot from the user, particularly because of how much you can twist it to your needs. It's also great when writing tests.
My take is that there was a time were monkeypatching and doing this nasty stuff everywhere was common (early days of python becoming mainstream). Some libraries might still do this, but they are well tested and supported, so not an issue for them. But most python code being written now does not make much use of these features.
About functional constructs, I mostly agree with you, but the various comprehensions are a joy to work with, and provide enough for the most common usecases; the recent `match` construct also makes it possible to simulate ADT, which is great.
Finally, typing is very mainstream now, great libraries such as dataclasses or pydantic make classes with typed fields very easy to use, with minimal boilerplate.
You never saw a line of assembler, didn't you? You also just discounted 40 years of computer science (EDIT: I mean programming, CS has longer history of course) that happened before advent of Python. Good job.
Well, separating them is just as arbitrary. From the perspective of type theory, both kinds are just unityped. I was responding to claims about dynamic typing - and to that, assembler is relevant, as it uses the same typing discipline.
Moreover, as others noted, the division between static and dynamic typing fans probably started with Lisp sometime in the '50s. The arguments for and against each typing discipline are mostly the same as they were way, way before Python existed. Some technological breakthroughs did change some aspects of a discussion, but the debate is mainly philosophical and treated as a social activity more than an engineering one. That helped it remain frozen in time for so long.
In any case, Python is most assuredly not what gave dynamic typing a bad name. Instead, what gave dynamic typing a bad name were developers with a strong preference for static typing. And on the other hand, what gave static typing a bad reputation - and it also does have one like that - were developers who liked dynamic typing more.
That statement is ahistorical and is impossible to defend without intensive goalpost-moving.