[mg74]

The number one thing I wish was addressed in future version of Python is the semantically significant whitespace.

Python is absolutely the worst language to work in with respect to code formatters. In any other language I can write my code, pressing enter or skipping enter however I want, and then the auto formatter just fixes it and makes it look like normal code. But in python, a forgotten space or an extra space, and it just gives up.

It wouldn't even take much, just add a "end" keyword and the LSP's could just take care of the rest.

GIL and JIT are nice, but please give me end.

[dbrueck]

Whitespace is semantically significant in nearly all modern programming languages, the difference is that with Python it is completely significant for both the humans and the tools - it is syntactically significant.

I've actively used Python for a quarter of a century (solo, with small teams, with large teams, and with whole dev orgs) and the number of times that not having redundant block delimiters has caused problems is vanishingly small and, interestingly, is on par with the number of times I've had problems with redundant block delimiters getting out of sync, i.e. some variation of

  if (a > b)
    i++;
    j++;

Anytime I switch from Python to another language for awhile, one of the first annoying things is the need to add braces everywhere, and it really rubs because you are reminded how unnecessary they are.

Anyway, you can always write #end if you'd like. ;-)

[ec109685]

The parent’s point was that you don’t have to care about white space when composing code in other languages since the LSP can auto format. So you could theoretically never press return or space more than once, and always have perfectly correctly functioning and formatted code at the end.

[dbrueck]

Oh, I thoroughly understand the parent's point, I'm just disagreeing that it is a problem that needs to be "addressed".

Most language design decisions involve tradeoffs, and for me this one has been a big positive, and the potential negatives have been - across decades of active usage - almost entirely theoretical.

Also, the real-world use case for importing code and auto formatting it is quite doable with Python - the main thing you can't do is blindly (unintelligently) merge two text buffers and expect it to work every time, but in general it takes only a smidgen of analysis on the incoming text to be able to auto reformat it to match your own. You could go all the way and parse and reformat it as needed, but much simpler/dumber approaches work just as well.

What you can't do is take invalid Python code and expect it to autoformat properly, but that borders on tautological, so... :)

[biorach]

> So you could theoretically never press return or space more than once,

There are people that actually do this?

[saagarjha]

Never commented out a loop or a condition, have you?

[dbrueck]

...yes? Sorry, I'm not sure I understand what you're getting at. :)

(funny enough, that particular scenario is actually harder to miss in Python since it often produces an error that prevents the program from running at all)

[saagarjha]

Ok, let's say I have some code. C:

  some_function();

Python:

  some_function()

I am debugging how this function works so I actually only want it to run when some condition is true. C:

  if (some_condition) {
  some_function();
  }

Python:

  if some_condition:
  some_function()

Oops. That's not indented correctly, so it won't run. To be fair neither actually looks good but that's 1. fine because this is for debugging and 2. for the C code I just format the file and it is instantly fixed. What if I have a loop? C:

  for (int i = 0; i < 5; ++i) {
      iteratively_optimize();
  }

Python:

  for i in range(5):
      iteratively_optimize()

Unfortunately this breaks something so I want to step it through. In C I comment out the loop as follows:

  // for (int i = 0; i < 5; ++i) {
      iteratively_optimize();
  //}

In Python:

  // for i in range(5):
      iteratively_optimize()

Nope, that's broken too. I can't just autoformat this code either because the formatter can't look at scope using anything else. I have to manually go and fix the indentation on that line too.

These are actually very small cases. I can even imagine you saying, in C you have to fix two places if you want to comment out a loop or if: the opening brace and the closing one. In Python you need to comment out the control statement and the second thing is fixing the indentation, so what's the big deal? Well, as the number of lines in the block grows larger in C it's still just commenting out the two braces, while in Python you have to select the whole region line-perfectly and fix the indentation. As someone who writes both I always find this to be a lot more fiddly and annoying.

[alfiopuglisi]

The day your wish is fullfilled is the day I stop working with Python. I can't stand all those useless braces everywhere, why are they there at all since good practice mandates proper indentation anyway?

I am at the point where I prefer single quotes for strings, instead of double quotes, just because they feel cleaner. And unfortunately pep8 sometimes mandates double quotes for reasons unknown.

[eviks]

Single quotes are also easier to type on the default layout, no Shift

[mg74]

No need for braces. Just add "end" for marking block ending to match the already block starting keyword ":".

[pansa2]

A while ago, when thinking about syntax design for a new language, I considered this combination (`:` and `end`, as opposed to `do` and `end` as used by Lua etc).

Are there any languages that use it, or is Python unique in using `:` to begin a block?

[dbrueck]

Nim uses it too.

IIRC, Python's predecessor (ABC) didn't have the trailing colon but they did some experiments and found it increased readability.

[stavros]

I don't have this problem, and I've been writing Python for more than twenty years. Sure, I may have the occasional wrong space somewhere, but it's maybe a few times a month, whereas I'd otherwise have to type "end" for every single block.

[mg74]

I dont think this is a problem anymore in todays world of LSPs and auto formatters. I almost never have to type "end" in Elixir for instance, it is always autocompleted for me.

[stavros]

How does it know when to end a block?

[tredre3]

The autoformatter does it based on indentation, but when writing code the editor just inserts it when you open a block (after your cursor), same way } is added when you type { in other languages.

[stavros]

Ahh OK, I see, thanks. I don't really see much difference with whitespace sensitive languages, I've never really had problems with it. Maybe I've been lucky.

[pansa2]

    >>> from __future__ import braces
    SyntaxError: not a chance

[mg74]

Thank you, but I rather not inject a tool that hasn't been updated in 6 years into my build chain. Thats how we do things in the Javascript world and frankly it sucks.

[benediktwerner]

This is a joke that's actually built into Python. The __future__ module is where you can import/enable features that will become the default in future versions. The point it makes by giving "SyntaxError: Not a chance" is that Python will never add braces.

And IMO for good reason. It makes the code so much cleaner and it's not like it particularly takes effort to indent your code correctly, especially since any moderately competent editor will basically do it for you. Tbh I actually find it much less effort than typing braces.

[marliechiller]

This suggestion gives me chills. I literally never face this issue. Are you using vim? Theres autoindent and smartindent features you can enable to help you.

[mg74]

Neovim + ruff lsp. I have gone through many formatters to try and get this better, but it is always worse than any other language where whitespace is not semantic.

[zo1]

The one nice perk about the state of things atm in python is I can very easily filter out devs by their choice of python IDE (or lack thereof).

[mixmastamyk]

Expecting formatters to fix your broken blocks is a false economy with Python and smart indentation. It takes fewer keystrokes to write Python correctly, than to add delimiters so you could write it incorrectly.

Python’s tradeoffs pay dividends every day, at the expense of few questions a year. Also code is read 10x more than written, where the extra delimiters lower signal to noise.

[ptx]

Maybe it would help to think of "enter" as "semicolon" (since it's the statement terminator) and configure a macro or shortcut in your editor to act as "end" which decreases the indentation level by one step.

Wouldn't that make it behave pretty much as what you expect?

[fluorinerocket]

Bracket free-ness is still my favorite part of python