That principle was bullshit anyway. There have always been multiple ways to do things, the one way was just whatever the elder Pythonista deemed to be pythonic that day.

Not true. The language optimizes for the way it is intended to be used, and changes remain sensitive to those optimizations.

"Pythonic" means intended usage, and "unPythonic" is shorthand for "you found another way to do it that kinda does what you want but (is ten times as slow/takes up ten times as much memory/doesn't work for edge-cases/has more unintentional side-effects) because it wasn't the intended usage, which is fine for your own personal projects, but please don't bring that into my code base, and pretty please don't teach other people to do it that way..."

Quite the contrary, it's very beautiful and useful:

    >>> (1, 2) == (1, 2)
    True
    >>> (2, 1) == (1, 2)
    False

If you need identity for perf:

    >>> (1, 2) is (1, 2)
    False

If you just need the type check:

   >>> isinstance((1, 2), type((1, 2)))
   True

It's very explicit, practical, and you can set the scale of practicality vs performances where you want. Plus: no implicit weird type conversion, only one equality comparison operator, and no hidden rules.

I think it's sane.

I’m not sure if you’re for or against here. Walking the container is exactly what you have to do, and it is horrible. More importantly, if it’s not your library, you don’t get any choice on how the equality check is implemented.

Iterators and callbacks aren’t comparable. You don’t use them for the same thing.

What do you think each(), map() and filter() do ?

But even without that, I'm not saying they are comparable. I'm saying the same API will use explicit anonymous callbacks in JS and something else in Python (decorators, subclassing, protocols, generators...). I'm saying that the same API will use __iter__ in Python and something else in JS (type conversion, proxy object, explicit method call...).

E.G, this is a Python pattern you'll find in contextlib or in pytest fixtures:

    @somekindofregistration
    def foo():
        print('code that runs before')
        try:
            yield
        except Stuff:
            print('Error handling')
        print('code that runs after')

This uses Python iteration mechanism to run code at 3 different times in a life cycle.

While in JS, you would pass 3 callbacks.

Map, filter, and fold are higher order functions, functions which take functions as parameters.

You are misusing the word callback. A callback is a function passed to another thread that will maybe be invoked later as a response (like it calls you back).

That's not what a callback is. A callback is just a function passed to an outer function that the outer function may call.

Even MDN uses the term callback to describe e.g. the argument to 'map': https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

In contrast, Lodash goes out of its way not to use the term "callback", presumably to avoid confusion since it's a place where many functions-that-take-a-function-argument do not call the provided function, e.g. https://lodash.com/docs/#curry

Second this. I can’t understand finding Python beautiful or even elegant. It just took a hodgepodge of features from languages like Haskell and C++, and repackaged them clumsily. It’s good for writing short scripts and throw-away code, but it shouldn’t be used as a serious programming language.

Computer archeology comes to rescue them all.