Python with Braces | Hacker News Reader

Python with Braces

web.archive.org

39 pointsorisomething75 comments

We changed the URL to the archive.org version because the original domain now points to malware.

Why do some people feel like meaningful indentation is a deal-breaker with Python? It makes for readable code even in curly brace languages like JS, Java, and C. In fact, I found the first curly brace example with the odd indentation jarring. Being able to quickly scan a block of code and get a sense for what belongs to which block is incredibly valuable.

In my experience the people that complain about it most are those who just like to slop things together and not bother with even the most cursory attention to detail. For people with that attitude having to worry about details like white space no matter how trivial "gets in their way".

I've had 20 years of dealing with C style parentheses and I've learned to parse it visually at a glance. I can't do the same with languages which use significant white space instead.

I imagine I could train myself to do so, but there is a cost involved.

I suspect if you were presented with a piece of code where the indentation and the braces disagreed, you would believe the indentation. Yes, it's easy to parse at a glance if it is correct, and the indentation agrees with it. If it doesn't, good luck seeing the error.

This is one of the good things about significant indentation: the human and the computer are reading the same signals.

while i concur, there is one shining example where this is a problem: fixing someone else's code where a bug has been introduced due to mistaken indentation.

last week i fixed a bug where a mistake in indentation (maybe a cut and paste in a refactor?) caused something to be done once but not the correct number of times (once for every iteration). took a few minutes to figure out where to look, but it took a few minutes more to figure out what was intended and what the bug ultimately was (the disconnect between what you meant and what you did). while this is a small 2 line example, for larger code blocks this is a serious problem.

i'm not advocating for braces, but they have a helping hand in spotting these sorts of bugs.

that said i often dislike it when people dismiss python just on the whitespace complaint alone.

I've committed plenty of indentation bugs in Python.

But I've also committed bugs due to putting something on the wrong side of a closing brace.

Please don't call manual copy-paste code changes refactorings. Here is the definition of refactoring :

> Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements. Many development environments provide automated support for performing the mechanical aspects of these basic refactorings.

If you attempt to do computer's work for them, you're going to screw up. I screw up manual refactorings in Java too (e.g. misspelling variable names, misspelling one of the gazillion xml file declarations), and much more than in Python. Don't do manual refactoring.

The real flaw is that the architecture of python makes automated refactoring impossible. This is not due to the indentation sensitivity of Python.

I usually run other people's code through a linter if I don't like their coding style and have to read it. It saves a lot of pain later.

I prefer not to be forced to use correct indentation. I do so as a matter of course. And on the odd occasion I have some reason to use odd indentation, I want to be able to do that too. I like to write my code according to my own judgement. I don't feel that indentation ought to be part of a language, just part of the code.

That said, I do sometimes write in Python and I have nothing against the language. This isn't meant to be an attack on Python.

Edit: also, the indentation in the first example is obviously just a means of illustrating that whitespace is non-significant with this project. I don't think they're suggesting code ought to be written without correct indentation.

> Edit: also, the indentation in the first example is obviously just a means of illustrating that whitespace is non-significant with this project. I don't think they're suggesting code ought to be written without correct indentation.

Does anyone anywhere have a realistic example of Python's indentation system being a hindrance? To me, the complaint always comes across as "I should hypothetically be able to do things that I would never actually do or endorse doing"

And it's not like there's no flexibility for weird corner cases. I mean, all of these things are already legal Python 3:

    for i in range(10): print(i)

    # although you wouldn't actually do this
    a = 3; b = 5; # a,b = 3,5

    # and you REALLY wouldn't do this but I couldn't help coopting their example

    if foo == "bar": _=(
        print("indenation"),
     print("doesn't"),
           print("matter!")
     )

Indentation rather than braces is probably the main thing that keeps me using Python over other languages. This project feels like a massive downgrade.

Would be very interested in projects that remove braces from other languages, though!

Something I like about Go is that there's a specified way to write your Go code, and the binaries are distributed with a tool to automatically format your Go code to the specification.

So, while you can write messy, unindented code, if you run gofmt over it, it'll look like everyone else's code (but probably still messy, because if you can't be bothered to indent your code, why would you be bothered to write clean code?).

Why do some people find that braces are a deal-breaker? I couldn't care less that python doesn't have them, i.e. its not a 'feature' at all for me. I much prefer having them.

In my experience writing python professionally (a while back), it was usually people who wrote very long methods with uneven nesting and single returns who had this complaint.

Guard statements and low cyclomatic complexity are important in all languages, but doubly so in python.

Maybe I'm being too harsh, but I feel like anyone who considers this a good idea isn't a sufficiently-Pythonic thinker to be writing Python anyway. Python isn't just a language--it's a culture, and one of that culture's core principles is that there should be one way to do it.

One of the best things about Python is that there's comparatively little "culture", at least compared to Perl, Ruby or JavaScript.

The culture/community that does exist is more oriented toward helping people achieve what they want to or need to get done, rather than smugly regurgitating alleged "best practices" (Ruby and JavaScript) or absurdity (Perl).

Yes, there are the PEPs, but they're more about providing useful guidelines that can likely offer some benefit if followed, rather than dictating the "best" way of doing something. Avoiding the typical Python approaches may raise some eyebrows or cause some confusion, but basically never the visceral lashing that one would be likely to receive within the Ruby community, for example.

Wow, now I really don't want to learn Python. (Psst, you have the most popular programming language. You can take off your persecution complex.)

I don't understand; You hate that Python is all about helping people get things done ? That repels you ?

What repels me is the defensiveness and the apparent need to criticize other language communities. I'm not interested in joining a cult.

Like many other people, I use Python, Ruby, JavaScript, Java, and several other languages on an ongoing basis.

We don't really care about "communities" or "cultures" and whatnot. We just have work that we need to get done using those programming languages. This isn't about "defending the Python culture" or "attacking the Ruby community" or any crap like that.

Having dealt with so many different communities over the years, the Python community is by far the best to deal with, from a practical standpoint. Whenever I've had a Python-related question, the members of that community have done their best to help me out with achieving what I want to do.

This is very different from the typical response from the Ruby or JavaScript communities, where they'll consistently tell you that what you're doing is "wrong" or against their "best practices" of the hour. That's not the kind of "help" that we're looking for.

Get all emotional about this if you want. That's your right. But the rest of us have pragmatic, real-world concerns. The Python community does an excellent delivering us with useful help when we need it. Certain other communities do not. Those are just the facts.

There may be a culture, but Python is simply a tool. One doesn't need to be a "Pythonic thinker" to use that tool. I'm not saying this is the most /sensible/ idea/project, but I see nothing in particular wrong with it. Your conception of culture here sounds oppressive and stifling to me.

Another commenter suggests the only reason to do something like this would be "emotional attachment"; all the huffing and puffing in these comments strikes me as exactly that, but in reverse.

I'd been gradually warming up to the idea of getting over my distaste for Python's surface-level quirks and digging in and finally adding it to my repertoire, but this comment has made me reconsider.

I think your criticism would be valid if the braces were optional and tabs still worked, but this version of Python is still a Pythonic language. (Or at least, it's no less Pythonic than your standard Python.)

> I think your criticism would be valid if the braces were optional and tabs still worked ...

Surely you didn't mean tabs?

https://code.google.com/p/soc/wiki/PythonStyleGuide : "Indentation: 2 spaces (no tabs), differs from PEP8"

PEP8 (http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces): "Tabs or Spaces? ... Spaces are the preferred indentation method. ... Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively."

It's generally a given that people use the word `tab` to refer to both hard and soft tabs.

Yes, and soft tabs are fiction. Prove me wrong -- show me a Python specification that tells us what "soft tabs" are and how they are to be used. Post the Unicode code point for a soft tab character.

Of course not. My editor, like any proper editor, automatically inserts spaces when I hit tab.

> Of course not. My editor, like any proper editor, automatically inserts spaces when I hit tab.

Which translates to "yes".

No, it translates to "it inserts soft tabs".

"Soft tabs" are fiction. Show me the Python specification that says "you cannot use spaces, you must use soft tabs". The fictional soft tabs suffer from the same defect as real tabs -- they're defined in different ways in different places.

Source: https://code.google.com/p/soc/wiki/PythonStyleGuide

Quote: "Indentation: 2 spaces (no tabs)"

Gee, that's funny -- no mention of "soft tabs".

Source: http://www.python.org/dev/peps/pep-0008/

Quote: "Indentation ... Use 4 spaces per indentation level."

Where are the references to "soft tabs"?

I can't believe someone skilled enough to do this has actually not realized why it is a colossally bad idea. Having a working compiler is just one tiny aspect of the problem. Unless there is a transparent way to interoperate with the rest of the Python ecosystem (libraries, tools), it is dead in the water.

Even then, this seems like a lot of work to overcome a non-problem, akin to developing a C++11 compiler which uses "begin" and "end" instead of braces because of some emotional attachment to Pascal. Really, if you are a programmer and the only thing stopping you from using Python to solve some problem is its indentation rules, you should stop and reevaluate your priorities.

Even then, this seems like a lot of work to overcome a non-problem, akin to developing a C++11 compiler which uses "begin" and "end" instead of braces because of some emotional attachment to Pascal.

The thing is, it's actually trivial to do that using the C++ preprocessor.

In fact, Steve Bourne wrote the Bourne shell exactly in this fashion, with the following C substitution macros (based on Algol-68):

    #define STRING char *
    #define IF if(
    #define THEN ){
    #define ELSE } else {
    #define FI ;}
    #define WHILE while (
    #define DO ({
    #define OD ;}
    #define INT int
    #define BEGIN {
    #define END }

Source: Expert C Programming: Deep C Secrets, p. 13. Peter Van der Linden. 1994.

(this isn't to deny that Python with Braces is a rather frivolous idea)

I'm mostly surprised that they went into the actual parser/compiler and modified that. If I were crazy enough to do this, I'd probably just write a pythonb-to-python compiler.

You know, when I first started programming and got attached to Python, I longed for significant whitespace in other languages, such as Javascript (which drove me to Coffeescript) and C (which just drove me nuts). I avoided languages like Java and C# because they had so much syntactic "noise"., because they were statically typed, and because they were clearly inferior languages.

And Lisp...well, I shuddered at the thought of learning Lisp because of all those parentheses.

Now, however, I don't give a damn about braces. I use Java if the job calls for it, and I've developed quite an appreciation for C#. I enjoy playing around with Lisp and recognize that it shares a lot of fundamental features with Python. I have a strong appreciation for C's power and control (but use it only under very certain circumstances and with great trepidation).

Python is still my go-to language because of its incredible ecosystem, but I no longer insist on using it for everything. I use the right tool for the job. I dropped Coffeescript in favor of pure Javascript, which I've come to appreciate as not a bad language, as long as you're aware of the traps.

For larger jobs, I usually seriously consider using a statically-typed language, because I know I'll either have to religiously write unit tests, or suffer a world of pain (and even then odd bugs will happen that otherwise would not have).

Point is, I suspect that very often, those people that insist on bringing the syntax from one language to another are either early in their career, or they're focused on the wrong thing. If the presence or absence of braces is the feature of a language that bothers you most, then you want want to reevaluate your priorities.

(that said, if this project was just a fun way to explore Python's internals and lexers/parsers, please carry on!).

Why shouldn't the syntax matter? If a syntax results in more mental overhead, it seems sensible to avoid it if possible. What seems up for debate is what actually results in more mental overhead, and what just takes some getting used to.

Kudos for having the motivation to pull this together, I guess!

I must admit, I don't get why anybody would be interested in using this. Even the headline snippet is an example of "what not to do."

Python's significant whitespace incurs the small overhead of requiring attention to detail when copying and pasting code - that's pretty much the only downside, and it seems strange to add a feature while boils down to "allow slopping indentation practice at the cost of extra syntax."

I thoroughly believe syntactic noise is an enemy of productivity. Good editors will help to some extent, but I find the process of reading (say) CoffeeScript much more pleasant than JavaScript. Each to their own, of course.

I literally shuddered when I read this.

Significant whitespace to me is one of the fundamental parts of Python that if messed with, makes it not Python.

Perhaps this will make it slightly easier for people coming from PHP, Javascript or one of the many languages that do use curly braces, but significant whitespace is a selling point, not a hinderance IMO.

The examples kind of feel like an introductory page to coffeescript, in reverse. I think it does a great job of showing why meaningful indentation is cleaner. Now I want it for ruby :)

Just playing Devil's advocate, but one very good use of {} is for real anonymous functions. I.e.

  map([1,2,3], lambda (x) {
    print x
    return x * 2
  })

That's one of the limiting reason why we can't have that in Python right now

I don't understand, this is already available with

  >>> from __future__ import braces

    SyntaxError: not a chance

Ok, I don't want to be mean but, why would some do all this work to workaround one of the coolest Python features?

I love it. If this could transparently convert to and from normal Python I could see wrapping it in an editor plugin so that the braces could be visible to those of us who prefer them, while the output could remain traditional Python for interoperability with an established codebase.

It would be simpler to just make an editor which displays a { after any end-of-line colon and lines with } before each deindent, without actually adding them to the file.

This is bad, and you should feel bad.

Hey, I will just say, I'm not the one who behind this project. This project belong to two people I familiar with. Maybe I can arrange more "official" response from them about this project. Though, I want to say, This discussion just prove one of the probable core concept of this project. You should have the ability to choose the syntax that is right for you. The language stays (pretty much) the same.

P.S. I don't program in Python at all. The last time I've programmed in Python was a few years ago, when 2.4 was fresh (and I would still claim I didn't even really programmed then). I think indention base syntax has its advantages and disadvantages. But it's not pure good.

Isn't this a bit early? It's not even March yet.

Huh? Lack of braces is one of the things I like about Python. Additionally, on many non-English keyboards braces are somewhat hard to write (e.g., on a Danish Mac keyboard it's a three-letter combo: Alt + shift + 8). Not having to write braces is nice.

One of the examples on the page says "indentation doesn't matter". But the thing is, it does matter - even if there are braces. Correct indentation means that your code is more readable. Python (the normal version without braces) enforces correct indentation, which is brilliant.

What really bugs me is when spaces and tabs get mixed together in the same file. That's godawful.

What if you want to make a dictionary?

you = {'are': 'screwed'}

Surely they accommodate this syntax in the scheme. The whole project would collapse if they didn't.

I don't see the ambiguity. Braces in expression position -> dict constructor. JavaScript is a fine example of how this is not a problem.

Actually, it is. It is very easy to confuse an object literal and a block in Javascript. In fact, in the book I am writing[0], I dedicate an entire chapter to using this ambiguity to write arsehole code. Here's another example[1]

[0] https://leanpub.com/underhandedjavascript or its alternate title: https://leanpub.com/jsinterviewquestions [1] Slide 21 (1-index): https://speakerdeck.com/chewxy/underhanded-javascript-how-to...

EDIT:

For those of you who do not want to click through my self promotional links, try this in your browser:

  {}[0] == true // false
  
  {}[1] == true // true
  
  !{}[0] == true // true
  
  !{}[1] == true // true

Do you have any non-contrived examples of confusing an object literal and a block?

Because as soon as you see this

    { identifier:

You know it's an object literal and not a block.

    if foo == bar {
        baz(), lorem(), ipsum()
    }

could be:

    if foo == bar:
        baz(), lorem(), ipsum()

or:

    if foo == bar:
        {baz(), lorem(), ipsum()}

Admittedly, this code doesn't have a functional difference. With a bit more thought, I may be able to come up with code where that matters.

Let's first forget that this is a crazy idea:

This is doable since dictionaries and blocks show up in different contexts. A block never follows =,:, ;, or (, so with a context sensitive grammar this can be accomplished. I guess it depends how they intend to support anonymous functions (def{}?)

I think I need to add a disclaimer:

- I'm not the one who behind this project - actually, I'm a not a real programmer (I'm a graphic designer who also code) - the people behind this project can be found in Github. At least I can say about one of the who is a close friend, that he codes in Python about 8 years as a profession - I'll ask him to open a user and add his thoughts to this discussion (if he doesn't have yet)

Depressing to think anyone on this earth finds curly braces an improvement to Python. I always prefer languages without, curly braces are ugly!

If someone really loves curly braces so much, there is no shortage of languages that offer them. This is like making a Lisp dialect without parentheses or a Smalltalk without messages.

Fair disclosure: I used a language called Actor that was pretty much Smalltalk without messages. I mean, there were messages. They just looked like function calls with the receiver as first parameter.

I almost did a spit-take when I read this. I actually do very little work in Python so I have no personal opinion on the subject, but I have a few close friends that are hard-core python programmers. I imagine the nerd rage that braces would incite. I'm gonna send this link to them now, sit back and watch chaos ensue. Bwa ha ha (rubs hands together)!

WHY????? Do you have endless empty time?

{ {because;} {language;} {improves;} {when;} {you add;} {curly braces;} {and;} {semicolons;} {to it;} }

I would actually use it with iPython

Woot! Ditto. :)

Score:

+1 : the idea of braces in Python

-1 : The fact that the project addresses an out-of-date Python version (2.7 instead of 3+).

Result: 0

I use 3.x myself but if I were to do something like this I'd probably target 2.x/the majority as well, at least at first.

This should be implemented as a editor plugin...with the actual files having none

Worst idea ever! It's like "upgrading" humans to walk on 4 legs.

Can we have this with explicit typing? (Not even a joke)

from __future__ import braces

  File "<stdin>", line 1

SyntaxError: not a chance

Please, no :(

i'm sorry, don't mean to be harsh at all, but this is just a bad idea.

This makes no sense at all.

Blasphemy!

Reply on news.ycombinator.com