Python with Braces

To some, significant indentation is better.

Others — too used to braces — miss them dearly in Python.

Next ones, vie for the non-text source code, something to get us past these discussions altogether (editors working on .pyc files directly?).

For programs to be maintained, they need to be read, understood and improved. One—often undervalued—skill in programming is to write beautiful code, because that is more art than craft. And unfortunately, tools like Black prohibit the true artists from expressing themselves clearly with code formatting too. And to those, white-space or braces matters on a different level, and everything else is attempting to make up excuses for why one is better than other.

And while conceptual operations we do on the code seem simple on the surface, devising an editing tool that would do semantic operations on the AST is fricking hard and likely to be very non-ergonomic. Look at all the attempts to make code refactoring tooling: it's crazily complex and confusing that it's simpler to just go and grep for a string and fix anything you find.

As long as it's faster to use regular editing operations to shuffle code around, indent or unindent it (or wrap it with braces), tweak one thing here or there, simple text editors will mostly rule the world of programming.

    if foo == 1: # {
        print "one foo"
    # }

    if foo == 1: # begin
        print "one foo"
    # end

    if foo == 1: # beginnen
        print "one foo"
    # 終了

    if foo == 1: # begin
        print "one foo"
    # }

    if foo == 2:
        print "one foo"
    # fi

    if foo == 1: # perform conditional foo value check
        print("one foo")
    # end perform conditional

Make python a lisp - indentation is just the number of brackets.

Hy - http://hylang.org

Antoine de Saint-Exupéry

Unfortunately, we still live in an era where humans have to adapt to technology rather than the other way around. From my perspective, this is particularly true for programming.

For me, Python is a good (though not ideal) mix of simple syntax and power. The language is characterized by low redundancy, meaning it uses fewer unnecessary characters like semicolons or curly braces to mark the end of a line. If a human can recognize the end of a line without special characters, then the compiler should be able to as well.

As someone with ADHD, I find it particularly difficult not to get distracted by these and other superfluous details. These small distractions add up and can become very burdensome. Interestingly, I found it easier to program in Assembler and Modula than in languages like C++ (MSVC), PHP, or JavaScript – at least as long as the projects were small.

Even a brief look at Rust’s syntax causes me almost physical discomfort, no matter how great, powerful, and useful the language may be.

For this reason, I almost exclusively use the terminal for emails, calendar, and programming, even though complex GUIs can simplify some tasks.

Although Python is not perfect in terms of syntax, it offers a good balance. Perhaps one day, before the perfect programming language exists, we will be able to use AI and ML to explain to the computer what a program should do with simple language (better than ChatGPT right now), just like Captain Picard. In fantasy, a few letters, punctuation marks, and some grammar is all that is needed. This may lead to inaccuracies in human-to-human communication, but that does not mean the same problems must occur in communication with an intelligent compiler.

Making syntax as “human-readable” as possible should always be the highest priority. We could unlock so much potential this way.

This transpiles into Python. Okay. So for this to work in a collaborative environment, EVERYONE working on the code has to use it. Given how popular python is, and the natural inertia of programming languages, I simply don't see that happening.

The reasons for this are legion: From programmers simply being used to how python looks, over IDEs and linters that would have to be remade, all the way to automated tooling.

And even if all that were not a problem: This introduces one more step and one more element into the build chain. Which is something I can't see DevOps doing, for a, at the end of the day, purely cosmetic change.

[0] https://github.com/yairchu/awesome-structure-editors/blob/ma...

[1] https://news.ycombinator.com/item?id=9495493

[2] https://web.archive.org/web/20151023070244/http://joelburget...

IMHO, some level of linting should be required. I would often have to reject lengthy and excellent pull requests (PRs), just because autoformat was not pressed and three instead of four whitespaces are in kotlin code. That annoys everyone. Python does that right, code won't compile with the three version whitespace, which is easily spotted before the PR.

Text editors are easy, but are waaaaay in the past. There could be much much better 3D like editors out there, but everyone is lazy to make one that would make your life much easier.

Now Ruby as his own defects of course. Static type can be integrated through Sorbet, but that still something out of the core for now. On that side, PHP had during the last years shown a far more remarkable pace in integrating many advanced feature for OOP (and functional stuffs are also progressing well). That said, the foundation of Ruby still win my preference in term of elegance and feeling of coherence.

I didn’t touch that much Python over the last few years. The only (significant) reason I would see it as opportune is its heavy use in ML and the like domains, and I didn’t have an opportunity to dig this domain much.

Also TS has slightly more consistent syntax for return types than Python. ``` // TS

function fn(a: Type, b: Type) : Type {

}

// Python def fn(a: Type, b:Type) -> Type {

} ```

But I want python to have to close braces on as few lines as possible. Yes I'm a Black user and wonder how.

They could fix the latter, but the REPL is Python tooling so it is required to be awful.

Pythons use their sharp, backward-curving teeth, four rows in the upper jaw, two in the lower, to grasp prey which is then killed by constriction; after an animal has been grasped to restrain it, the python quickly wraps a number of coils around it. Death occurs primarily by cardiac arrest.

https://en.wikipedia.org/wiki/Pythonidae

IMO lack of support for them (because of the lack of a good syntax) is the main downside of Python’s significant indentation.

https://github.com/umlet/pwk

Despite node feeling more verbose, I've found that I understand node easier than Python. It's definitely strange to me, because there can't be that much difference between the 2, but parentheses seem to make it easier to follow structure?

This seems contradictory. But I see the benefits. Perhaps braces and an official linter would be a more ergonomic approach.

PR #1: Makes Bython self-hosting

self.onandonandon is a real pain along with copy.deepcopy

Troll. 100%. A good one at that.

  >>> from __future__ import braces
  File "<stdin>", line 1
  SyntaxError: not a chance
  >>>

This is how Python got big: Discuss cute issues endlessly, pretend to be a funny, benevolent community. But real issues like performance, correctness or security are never addressed, and people who dare to mention them are punished severely.