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

51–60 of 71 posts

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

#51

Post by tommiegannert »

driggs wrote: post #29
wwfn wrote: post #14

Earlier quoted context omitted.

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.

I very strongly disagree. The most successful implementation of literate programming is the Jupyter Notebook, formerly called iPython Notebook. Even when you write it as raw markdown, there's no issue mixing documentation with triple-backtick code blocks. Maybe you're thinking of mixing Python with HTML? Python based HTML templating can be ugly, and the significant indentation of Python is a very poor mix for replaci…

> there's no issue mixing documentation with triple-backtick code blocks.

Your argument became: By adding delimiters, even Python can play well with other languages. /s

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

#52

Post by Yizahi »

dgfitz wrote: post #34
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.

The problem is that in the year 2024 there are no real technical arguments against tabs. I suspect very few people saw any tab mangling system ever in their lives or even at all. We are like monkeys from the anecdote about bananas and waterhose. All the population has been replaced multiple times and waterhosse is long dead, but we are still afraid to touch the forbidden fruit.

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

#53

Post by scotty79 »

sanderjd wrote: post #39
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 :)

I tried using Idea for Scala 3 where indents are meaningful. I prefer size 4 tabs for indents. There were four knobs for adjusting indents and until I adjusted all of them the IDE was messing up my indents in subtle ways. If leading editors have trouble abstracting indentation from its textual representation I have zero hopes for them being able abstract even such simple element of AST as a block.

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

#54

Post by cma »

kstrauser wrote: post #50
cma wrote: post #49

Earlier quoted context omitted.

That's what I meant by backwards though. Especially in UI OnClick code etc., I'd rather know the context that this happens on click of whichever object it is, but instead I have to write the clicked code before the code that registers it with the object, whose name has more relevant info, and then I end up having to name an extra thing too and keep the name in sync

But you can use a named function anywhere you'd use a lambda, in exactly the same way, just literally one line above where you'd pass the lambda to another function. It's not like you have to write the named function up at the top of the file. You can define it right there where it's going to be called. Truly, it's so easy and cheap to make a named function that I've never really missed having lambdas.

Its backwards when you read it and redundant.

    def do_on_click(): # What's being clicked? 
        foo()
        bar()

    backup_system_panel.reset_button.bind(on_click=do_on_click())
Oh it's the backup system, maybe I should have named it that. Now I have to worry about reading backwards or keeping names in sync. Having to give it a descriptive name is like uneccessary comments. Giving it a temp name is ok but then you are reading bottom to top to know what is going on like you are programming in reverse polish notation or something. It can be multiple lines and scrolled off the screen before you know the context it is used in, instead of just being able to read top to bottom and get everything. Most other languages let you just stick it in line where it is used. It's error prone like C variables when they had to be declared up top.

Sometimes in other contexts it does make sense to do, but with other languages you can choose to pre-declare and name it or not. In python often you see code with all the error handling lambdas up top before you even know what is going on, when exceptions aren't a good fit.

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

#55

Post by diggan »

Yizahi wrote: post #52
dgfitz wrote: post #34

Earlier quoted context omitted.

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.

The problem is that in the year 2024 there are no real technical arguments against tabs. I suspect very few people saw any tab mangling system ever in their lives or even at all. We are like monkeys from the anecdote about bananas and waterhose. All the population has been replaced multiple times and waterhosse is long dead, but we are still afraid to touch the forbidden fruit.

> The problem is that in the year 2024 there are no real technical arguments against tabs.

Since you added "real" in there, no argument really matters. But regardless, it's funny you say that, as Python current style guide (https://peps.python.org/pep-0008/) outlines 4 spaces as the one and only correct way of writing Python code.

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

#56

Post by Yizahi »

diggan wrote: post #55
Yizahi wrote: post #52

Earlier quoted context omitted.

The problem is that in the year 2024 there are no real technical arguments against tabs. I suspect very few people saw any tab mangling system ever in their lives or even at all. We are like monkeys from the anecdote about bananas and waterhose. All the population has been replaced multiple times and waterhosse is long dead, but we are still afraid to touch the forbidden fruit.

> The problem is that in the year 2024 there are no real technical arguments against tabs. Since you added "real" in there, no argument really matters. But regardless, it's funny you say that, as Python current style guide ( https://peps.python.org/pep-0008/ ) outlines 4 spaces as the one and only correct way of writing Python code.

The emphasis was on the word technical. The only technical argument I've ever heard against using tabs for indentation only, was that some software text editor a long time ago mangled tabs. In my anecdotal experience with computers plus working with some embedded telco hardware dating back to 2000 and some even earlier, some with rather old or non mainstream OS, I've never ever seen a text editor which mangled tabs. Nor I've never met anyone who seen that happen. Maybe it happened in the mainframe age, but I suspect even that software has been upgraded over time.

Sure, PEP8 an other standards prescribe spaces, and I of course always use industry standards myself too. I'm just saying that there is no technical merit for that demand. The water pipe in the monkey cage has long been shut down. The only reason to demand spaces for indent now is circular - that other standard is demanding them, therefore we need to do the same, and that other standard uses the same circular logic himself.

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

#57

Post by xigoi »

Yizahi wrote: post #52
dgfitz wrote: post #34

Earlier quoted context omitted.

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.

The problem is that in the year 2024 there are no real technical arguments against tabs. I suspect very few people saw any tab mangling system ever in their lives or even at all. We are like monkeys from the anecdote about bananas and waterhose. All the population has been replaced multiple times and waterhosse is long dead, but we are still afraid to touch the forbidden fruit.

Technical argument against tabs: they don’t play well with auto-formatters that enforce a specific line width.

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

#58

Post by xigoi »

everyone wrote: post #40
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.

Indentation is very much visible.

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

#59

Post by xigoi »

cma wrote: post #12
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…

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

That has nothing to do with significant indentation. Other languages with significant indentation (Nim, CoffeeScript) support multi-line function literals.

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

#60

Post by xigoi »

tom_ wrote: post #35
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…

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…

You have to press return instead of a semicolon, which is the same amount of keystrokes, and tab instead of a curly brace, which is fewer keystrokes. What problem do you have with that?

Also, Python has a great auto-formatter, Black.

Post reply on HN