Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Python with do..end in place of strict indentation

github.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Show HN: Python with do..end in place of strict indentation

#31

Post by sanderjd »

HexDecOctBin wrote: post #11
Sohcahtoa82 wrote: post #9

Earlier quoted context omitted.

When I hear someone complain about the whitespace thing, it sends a message to me that they do not format their code well and just go willy-nilly on their indentation. If you're properly indenting code, then it always works as intended . Proper indentation doesn't come from a desire to make the code work, it comes from a desire to make it readable. It just happens that readable means correct in Python's case. It lite…

I just translated all my build scripts written in Python to straight C due to indentation issues. Not because I don't format my code properly, but because any time I refactored my code, I ended up with dozens of subtle indentation related bugs that took hours to find and fix. If your language requires an IDE, then you have become Java.

I don't relate to this at all. I don't understand how you refactor, in either python or C or anything else, without fixing indentation after you move code around. Yes, in C you don't have to fix the indentation in order to get it to compile and run, but that doesn't mean you don't have to fix the indentation! You can't just leave it inconsistent, that's insanity.

Re: Show HN: Python with do..end in place of strict indentation

#32

Post by sanderjd »

kstrauser wrote: post #17
cma wrote: post #12

Earlier quoted context omitted.

Not being able to nest multiline lambdas into function arguments where they are called makes you have to read a lot of code backwards.

I do wish it had lambdas. That's largely mitigated by the fact you can define functions pretty much anywhere. Instead of: def my_func(): another_func(lambda: ...) you can write def my_func(): def inner(): ... another_func(inner) Sure, it's creating a function, naming it, then immediately throwing it away, but gets the job done with minimal extra boilerplate.

Yep, I find python's lambda syntax to be probably its worst conceived feature. But just defining a named inner function works great for all the same use cases.

Re: Show HN: Python with do..end in place of strict indentation

#33

Post by Jtsummers »

wwfn wrote: post #14
driggs wrote: post #7

Anyone who can't see past Python's indentation-based syntax is a person who doesn't understand Python. (Both literally and figuratively!) When "significant whitespace" is at the top of someone's complaints about Python, I'm immediately done hearing about their superficial criticism of the language.

Literate programming tools that weave/tangle code and documentation don't play well with significant whitespace. Not a problem for me, but I think it's on a valid line of complaints.

Which ones? Org mode's babel works fine with it. If you do something like this (loose, not precise babel syntax):

  >=
    if 1 == 1:
        print('1 == 1, shocking!')

  >=
    def foo():
      >
It will generate properly indented code when tangled as in:

  def foo():
    if 1 == 1
        print('1 == 1, shocking!')
Note that it puts in precisely two extra spaces for each line in the tangled `body`, which is the amount used in the block named `function` where it references `body`. If you used 4 spaces of indentation, it would use 4 in the tangled output. I've also used noweb and don't recall this being an issue, however that was not with Python so it's possible I just didn't notice a problem with it.

Re: Show HN: Python with do..end in place of strict indentation

#34

Post by dgfitz »

driggs wrote: post #7

Anyone who can't see past Python's indentation-based syntax is a person who doesn't understand Python. (Both literally and figuratively!) When "significant whitespace" is at the top of someone's complaints about Python, I'm immediately done hearing about their superficial criticism of the language.

I agree. I think it’s only an issue because we as a collective didn’t sort out a tabs-vs-spaces debate and new people to the language struggle with that bit.

Re: Show HN: Python with do..end in place of strict indentation

#35

Post by tom_ »

Sohcahtoa82 wrote: post #9
driggs wrote: post #7

Anyone who can't see past Python's indentation-based syntax is a person who doesn't understand Python. (Both literally and figuratively!) When "significant whitespace" is at the top of someone's complaints about Python, I'm immediately done hearing about their superficial criticism of the language.

When I hear someone complain about the whitespace thing, it sends a message to me that they do not format their code well and just go willy-nilly on their indentation. If you're properly indenting code, then it always works as intended . Proper indentation doesn't come from a desire to make the code work, it comes from a desire to make it readable. It just happens that readable means correct in Python's case. It lite…

Python forces you to properly indent your code because the language is designed in a way that means the computer can't do it for you.

Once I'd become accustomed to languages where automatic formatting is feasible, having to do any of this sort of thing by hand started to feel like a real imposition. I didn't object to this aspect of Python when I first learned it, because it didn't feel much different from writing my C code, but now, after years of clang-format (and Visual Studio's auto format, and gofmt on the occasions I've been forced to use Google Go...) I just can't be bothered. How dare it make me press return. How dare it make me press tab. I have better things to do with my life than what I can only describe as this. fucking. shit.

Re: Show HN: Python with do..end in place of strict indentation

#36

Post by sanderjd »

airstrike wrote: post #13

I used to code in Python for everything in the late aughts and loved meaningful whitespace. Whenever I used a language with braces like JavaScript, for instance, I felt like I was still indenting code meaningfully but now I had the extra hurdle of also caring about the braces. It felt unnecessary and stone-agey. But back then I was just using vim with a nicely configured .vimrc. Linters weren't really a thing, or at…

I feel like your conclusion is backwards based on your argument...

> I also have the benefit of the compiler screaming at me if I forget a brace, pointing to the exact error including telling me when indentation is suggesting a brace is missing!

What the compiler is telling you here is that the braces are superfluous, because the indentation is already describing the structure correctly. So why bother?

My take is that in the (amazing!) new world with near universal usage of standardized linters, this whole debate is stale, it just doesn't matter either way. Everything is indented properly, whether or not it is necessary for correctness. So whether there is a bit of additional bracing or not, who cares?

Re: Show HN: Python with do..end in place of strict indentation

#37

Post by dgfitz »

HexDecOctBin wrote: post #11
Sohcahtoa82 wrote: post #9

Earlier quoted context omitted.

When I hear someone complain about the whitespace thing, it sends a message to me that they do not format their code well and just go willy-nilly on their indentation. If you're properly indenting code, then it always works as intended . Proper indentation doesn't come from a desire to make the code work, it comes from a desire to make it readable. It just happens that readable means correct in Python's case. It lite…

I just translated all my build scripts written in Python to straight C due to indentation issues. Not because I don't format my code properly, but because any time I refactored my code, I ended up with dozens of subtle indentation related bugs that took hours to find and fix. If your language requires an IDE, then you have become Java.

Hours? And C was a better option for scripting than python?

I’ll give you the benefit of the doubt, this sounds very curious.

Re: Show HN: Python with do..end in place of strict indentation

#38

Post by dariusj18 »

driggs wrote: post #7

Anyone who can't see past Python's indentation-based syntax is a person who doesn't understand Python. (Both literally and figuratively!) When "significant whitespace" is at the top of someone's complaints about Python, I'm immediately done hearing about their superficial criticism of the language.

My problem with indentation as significant is when I paste a chunk of code inside some chunk that is indented differently. Some may say that a good text editor will deal with that for you, but it's rarely been the case for me. The most is when the code is longer than my screen height and I have to scroll down and figure out where the pasted chunk ends and indentation it all who knows how many times without scrolling back up to the top of the chunk.

Re: Show HN: Python with do..end in place of strict indentation

#39

Post by sanderjd »

scotty79 wrote: post #20

Seeing code blocks as braced or meaningfully indented should be a switch in your IDE.

Yeah I once saw a great talk at a functional programming conference by a Scala compiler developer, making the point that programming language semantics should be specified at the AST level, with syntax entirely up to the user's whim.

I consider this to be both totally sensible and completely impractical :)

Re: Show HN: Python with do..end in place of strict indentation

#40

Post by everyone »

driggs wrote: post #7

Anyone who can't see past Python's indentation-based syntax is a person who doesn't understand Python. (Both literally and figuratively!) When "significant whitespace" is at the top of someone's complaints about Python, I'm immediately done hearing about their superficial criticism of the language.

I dont think it's superficial. Having characters that are invisible affect your code is weird and bad.

Which is a shame, cus otherwise Python is good imo.. I feel like its creator just had a weird whitespace fetish or something.

Post reply on HN