I’ve been coding around 25 years and got my start in perl. I absolutely hated python when I first used it. I use it all the time now. I still prefer my curly braces but I don’t have any trouble with python or mind the whitespace anymore. I just run it through ruff every save. I do the same with go everything goes through gofumpt. I really think a lot of it is a generational thing. Older people are just used to curly brackets.

I do get peoples complaints about the packaging. Unless you’re a dev already it’s a bit extra to deal with shuffling virtual environments because the system python environments almost never work out of the box, at least in the last few distros I’ve used. Once I adjusted though it’s no problem. I run half my dev stuff in toolboxes with their own environment anyway.

its just not as clear especially when u are indenting stuff inside stuff with a bunch of conditions everywhere its hard to read just from indentation, and with the () or {} u can just click on it and most text editors will show u from where to where its going.

Try finding a bug related to indentation in a 15 year old python codebase by the worst programmers on the planet. You won’t think that there’s no issues with it after that point. In any other language you literally just reformat and you’ll see the bug. That’s not the case in Python.

I have never had any problems with it either but don’t get me started on YAML.

I once wrote a bot in python tdownloaded a ical file, looked for chances and informed me if found. The space indentation made it hell to follow the code in my opinion.

I mainly found it annoying while writing code, because the lack of braces makes it difficult to tell when a scope ends. Plenty times, I’ve wanted to add something to the end of a for-loop, but had too little indentation.
Usually this means I get a runtime error, because it can’t access some variable from the loop-scope. But worst case, it only executes once after the loop and I don’t notice the problem.

Another big thing I miss when not having explicit braces, is opening up new/anonymous scopes to isolate variables, which helps prevent mistakes down the line + reduces code complexity.

For example, this is a thing I do quite regularly:

let client = {
    let client = new Client()

    let timeout = config.load("client.timeout")
    client.set_timeout(timeout)

    client //implicit return value of this scope when evaluated as an expression
}

client.request_something()

It allows me to visually group the initialization code for the client and I don’t need to have the timeout variable in scope afterwards. Depending on the language, you can also have the client variable mutable inside the scope and then immutable outside.

Yes, this could be pulled out as a function to achieve something similar, but in my experience people (including me) will often just not do that, because it’s only the timeout variable or whatever.