In my opinion, if standard tooling is able to identify the foot-gun, it’s not too terrible of a foot-gun. I don’t think standard python tooling would catch the above issues, but standard JS tooling would identify a missing variable declaration. As for the other things you mention (this, namespaces), I never said JS was perfect! Just that JS got a lot of shit for its scoping, fixed the problem, and now has sane scopes. Py has scoping with a lot of the same problems JS used to have, but for some reason didn’t fix them, and thus to this day is riddled with these foot-guns.

> I don’t think standard python tooling would catch the above issues,

Of course it does.

    $ echo "
    > powers_of_x = [lambda x: x^i for i in range(10)]
    > [f(2) for f in powers_of_x]
    > " > test.py
    $ pylint test.py
    ...
    test.py:2:27: W0640: Cell variable i defined in loop (cell-var-from-loop)
    ...

Pylint is the most powerful linter for Python is well integrated in VSCode or PyCharm.

When concerns are raised about JS, people are quick to answer you are not supposed to use it without modern tooling (Webpack + babel + typescript + eslint + lowdash...), although many devs still do.

Now, I use and teach a lot of JS, and I enjoy many of its modern features. I especially like the object destructuring, it's even better than Python's unpacking.

But objectively, you can get a very decent experience in Python without any kind of tooling. And yet, there is a lot of it if you want to up your game: pylint, black, mypy, jedi, pytest, poetry, etc.

That’s good to hear. As I said, I don’t use python much anymore.

Are they really foot-guns? The lambda variable reference thing has appeared more in forums comparing languages than I’ve seen it used at all in python and I’ve spent a lot of time working in large open source python projects with thousands of contributors.

Even if you got the binding right, your powers of 2 would be shot down for being unpythonic anyway due to lambdas being shunned when there are cleaner ways to write things.

powers_of_x makes no sense as a variable name for a list of functions that you have to call in order with the same number to actually get the powers of that number. I get that it’s just a contrived example, but most can be turned into someone more apparent to the reader.

    def powers_of_x(x, limit=10):
        for i in range(limit):
            yield x^i

Less memory, no anonymous functions, more flexibility, testable...

Modules avoid the variable issue because ‘use strict’ is applied by default for them.

IMO JS as a language is in a much better place than Python currently. I end up frustrated a fair amount by arcane errors in Python due to less expressive constructs or some wtf issues like unexpected variable scoping within Python modules.

This is most probably because you are trying to code in Python like you code in JS: this always leads to frustration.

I started to have fun coding in JS the day I accepted it was not Python and that I had to structure and style my code differently.

E.G: in Python you will use iteration a lot. A lot of a lot. But not so many callbacks. The reverse is true in JS.

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

After a long time using both languages, I’d argue that non-sane equality checks in js is the biggest source of bugs.

Unfortunately, this is not true. Although the equality operators are a favorite bikeshedding topic, the largest source of errors in JS code bases are type errors. Using a "non-sane" equality check, such as those with type coercion would actually mask or alleviate these source of bugs you mention.

I was thinking more of the case where the types match but objects and arrays with the same contents are considered different. I’ve watched every member of my team get stung by it again and again - and then have to create workarounds to get past it.

I don’t agree and this behavior shouldn’t be surprising. The alternative would be to walk the container and compare the value of each element, which could be horrible.

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.

> I agree totally with that, it's an ugly trap in python, although mitigated by the fact the language doesn't encourage this kind of paradigm so you rarely encounter it.

This. I've made this mistake exactly once in the last 7 years, but that one time almost caused a security issue.