Python with Braces

Re:Python with Braces by zzo38computer on Monday July 08, 2024 @03:53PM (#40908896)

I prefer using braces to delimit blocks (although the code will be indented, too), and semicolons to separate lines (the "automatic semicolon insertion" is, in my opinion, one of the worst features of JavaScript). Sometimes I will deliberately indent code in an unusual way, e.g. temporary debugging code might be not indented at all (although such things are not usually present in the final code; they will usually be quickly removed after being added, and such temporary debugging code is often are not committed to the version control system).

The ability for GCC and Clang to diagnose misleading indentation can be helpful; some programmers may wish to use it (and others may prefer to disable it). However, apparently it treats a tab as a number of spaces; I think that it should not do that, and using tabs on some lines and spaces on other lines to measure indentation within the same block, should always be considered misleading indentation (so if -Wmisleading-indentation is enabled, then it should always display a warning message in that case).

[ Parent | on HN ]

Re:Python with Braces by necovek on Monday July 08, 2024 @05:44PM (#40910064)

Do you deliberately "misindent" the code or is it mostly because it's hard to reindent and then back the change out? If the latter, that's obviously a different use case and one can use syntax tricks to achieve the same with Python if you don't want to have your editor help with that for whatever reason.

[ Parent | on HN ]

Re:Python with Braces by zzo38computer on Monday July 08, 2024 @06:55PM (#40910655)

Deliberately, both in order to mark it in a special way to stand out clearly, as well as to avoid having to add indentation for such a code where it is unnecessary and not helpful. That line of code will soon be deleted anyways, so it does not matter much if other people dislike it.

[ Parent | on HN ]

Re:Python with Braces by necovek on Wednesday July 10, 2024 @01:57PM (#40929565)

Can you share an example where you non-temporarily add braces around a code block but then keep the indentation the same level as before the block? What do your collaborators think of it?

[ Parent | on HN ]

Re:Python with Braces by kazinator on Tuesday July 09, 2024 @12:28AM (#40912536)

I also sometimes misindent some temporary debug print statements. However, indenting them right is just a matter of typing == in vim, while the cursor is somewhere on the misindented line.

Moreover, the ] modifier before p or P (paste below or above current line) adjusts the paste to the indentation of that current line. It takes next to no effort to copy and paste some code to the correct indentation.

Backing changes out nowadays is done with "git checkout --patch".

[ Parent | on HN ]

Re:Python with Braces by necovek on Wednesday July 10, 2024 @01:55PM (#40929549)

Getting indentation right with editor support is trivial in Python too (in Emacs, TAB does what you describe anywhere on the line, and when there are multiple valid options, it cycles through those).

Pasting blocks into right indentation or reindenting entire blocks too. So I am glad you agree it's simple to do any of these even with significant whitespace ;)

I wouldn't know about other editors, but I'd be surprised if it's not so in every one of them.

Where indentation really matters for temp debug statements — you want to enter a block unconditionally or skip it unconditionally — there are other syntactic tricks like add `True or`, `False and`, return, continue, break, semicolon, etc. But these are all temporary examples you are giving, and this only matters if editor is not supporting you.

And that's my point: these are trivialities and I can't stop being perplexed that people get so fussy about it.

I am not sure how git plays into this? It works exactly the same for Python, it's not like Python is bf with space as the control character.

[ Parent | on HN ]

Re:Python with Braces by kazinator on Monday July 08, 2024 @10:07PM (#40911883)

That's a tricky requirement because some GNU programs do exactly that: use mixtures of tabs and spaces. For instance, the first three logical tabs are groups of 2 spaces, so 6 spaces. The fourth tab, however, turns into single hard tab.

I think that to do this right, there would have to be a complex option in which you specify the tabbing style. -Widentation=<notation> where <notation> is some way of specifying the style.

There has to be allowance for alignment also. Any line, regardless of indentation method, can terminate in one or more spaces that exist for aligning the fist non-whitespace character with something in the previous line.

[ Parent | on HN ]