[Sohcahtoa82]

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 literally takes me zero thought to get indentation right. If you can't tell when to start or end indentation level, then I'd question if you know when you need to use an open/close brace in other languages.

I mean, yeah, sometimes copy/pasting code doesn't work precisely as intended, but all you have to do is select the code, hit Tab or Shift-Tab, and any sane editor will add/subtract an indentation level to the code.

[HexDecOctBin]

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.

[sanderjd]

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.

[wakamoleguy]

Of course you can leave it inconsistent! If whitespace is insignificant, you can move things around however you want and use (frequent) runs of a code formatter to clean things up for you. If whitespace is significant, it must be fixed manually line by line.

[sanderjd]

Code formatters work just fine in python. If you're running a code formatter frequently, that is not "leaving it inconsistent".

[wakamoleguy]

If we’re talking about pasted code not having the proper indentation, that’s a major difference between languages with and without significant whitespace. A formatter can fix that in C, but not in Python. Additionally, manual fixing of the indentation is required first.

[sanderjd]

I just don't think this is really a problem. My editor doesn't actually have trouble putting pasted code at the right indentation level...

[kstrauser]

Python doesn't require an IDE, but you'll definitely want to use a programmer's editor with it. I don't know what you're using that doesn't handle its indentation correctly because I haven't seen anything like that in at least a decade, but you may wish to upgrade to at least a newer vim or emacs.

[dgfitz]

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

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

[HexDecOctBin]

Pretty much. Partly because I have developed a pretty robust C standard library that I allows for writing code that is not too dissimilar from the kind of Python I was writing. And one shot processes mean that I can simply allocate memory without having to free it (and use arenas for one script that is a long-lived file-watcher).

[gunian]

why? black automatically formats code

[simonw]

What text editor do you use?

[tbrownaw]

> 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.

That's quite the assumption.

[cma]

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

[kstrauser]

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.

[cma]

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

[kstrauser]

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.

[cma]

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.

[int_19h]

One trick for this is to use the decorator syntax, e.g.:

   @foo.on_click
   def foo_clicked(): ...

Of course, for this, foo.on_click needs to be a callable function rather than a property.

[sanderjd]

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.

[xigoi]

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

[cb321]

Because of Python's prominence and the divisiveness of significant indents, there is a large amount of misattribution of "whatever Python's syntax choices are" to "must be needed by significant indentation". E.g., whenever I go from Nim back to Python, I get annoyed that `t = 0; for e in x: t += e` is illegal in Python (Yes, I know `sum()` exists - it's just another easy syntax example to amplify your lambdas one.)

[dgfitz]

It also makes hard-to-maintain code. Trade-offs.

[tom_]

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.

[xigoi]

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.