[rkangel]

I'm not a fan of 'multiparadigm'. As another comment on this branch says, the Zen of Python covers this quite well:

> There should be one-- and preferably only one --obvious way to do it

There are already 20 different ways of solving any given problem or of coding any given solution. At least if a single paradigm is used, then those familiar with it are unlikely to run into big surprises about how things are implemented. If your developers are used to an imperative style, a chunk of code in the middle of the codebase written in a strongly functional style is very difficult to comprehend.

In one tool I wrote for work, I use function application to progressively transform a stream of events. It's a beautiful, neat solution to the problem, but confuses the hell out of everyone else because they've never written any Haskell. There are other ways to implement this that are just as clear and abstracted and maybe they take slightly more code, but it is code that is more maintainable by everyone else. Good code to me is not that which looks like it was coded by a genius, but that which looks like any child could have written it. For some code this is very hard, but I find it easier in Python than other languages.

The more 'choices' that you have, the more inconsistency there will be about who chooses what. There is obviously a tradeoff here with giving developers the right tools for the job, but list comprehensions are a great example of how you can do that without having to use a different paradigm.

[coldtea]

>> There should be one-- and preferably only one --obvious way to do it

And then it offers 20 equally good ways: generators vs comprehensions vs iterators vs foreach loops vs map and filter, async vs threadpools vs processpools, and so on.

[pfranz]

It's tough to adhere to that principle, but its nice to see as a focus. Python wasn't even object oriented originally (and a lot of their standard library shows it). Guido has said he wishes he never added functional concepts like map and filter. Deprecating things hasn't been taken too well by the community.

[zephyrfalcon]

The first public release of Python, 0.9.1, was object-oriented. It had classes, and everything was an object internally, although admittedly not every type had methods yet (from a user perspective), esp. immutable types like tuples, strings and numbers. These methods wouldn't appear until 2.0, if I recall correctly. Types like lists and dicts had methods from the start.

[jxy]

> I'm not a fan of 'multiparadigm'. As another comment on this branch says, the Zen of Python covers this quite well:

>> There should be one-- and preferably only one --obvious way to do it

Unfortunately this was true ten years ago. Now, python is just following C++ and become this behemoth of features, especially with recent PEPs, which aim at saving one or two lines of code.