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.
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…
Speaking only as myself, usually when I find myself having the scrolling problem the function/method is crying out to be broken down and refactored anyway.
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 tha…
It's much easier to navigate to the end of a codeblock in the editor with vim. I can't do the same without braces. I admit this is an irrelevant argument if you're outside the vim echo chamber...but it's a pretty big echo chamber
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.
It's weird and fine.
I always find this take funny, because I have lots of problems with python, but this one has always struck me as the most superficial of the common criticisms.
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…
Regarding your Claude copying flow, there's a Python-compatible alternative. In nvim, you can use treesitter selections to select a block, and treesitter is aware of the indentation.
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.
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.
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.
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).
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.
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.
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
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.
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.