What I hate about python/yaml/etc is that copy/paste + reformat does not work.
Yes it forces clean indentation, but it gives the writer the burden to take care of it. That sucks. Let the computer do the work.
Yes it forces clean indentation, but it gives the writer the burden to take care of it. That sucks. Let the computer do the work.
An IDE with proper language support for a whitespace-aware language should be able to parse the AST figuring out the code structure from the indentation level; then it could reformat it at the proper indent level when you copy and paste it elsewhere, just like it does with a delimiter-based language.
No; it is not decidable where a block ends and the next line of the out block starts when there is no marker for block ends ('}', or 'END', etc).
No, it's not. The programming language grammar can reject things, but it cannot determine certain class of mistakes which explicit terminators ("}" and so on) can, which is why programs like `indent` existed for decades for other languages, but have yet to exist for Python which is already 30 years old.
If no one has cracked that particular nut for 30 years, you can't with a straight face claim that it is obviously possible. It looks more impossible with each passing year.
If you're talking about failing to determine blocks which are NOT correct Python, then I don't have a problem with those failing to be correctly indented under copy/paste. The vast majority of use cases would still be well served.
Then maybe you shouldn't have replied to parent who said:
>> Yes it forces clean indentation, but it gives the writer the burden to take care of it. That sucks. Let the computer do the work.
> The vast majority of use cases would still be well served.
Well, sure, because the burden for ensuring the code is correct falls onto the programmer, whereas with other languages we can just let the computer do that.
I replied to dismiss your assumption that adding delimiters as '}' or 'END' will ensure the correctness of code in a way that a code with indentation delimiters can't do. It's similar to saying that in, a language where statements are not finished by semicolon, it's not decidable where sentences end, so this forces the developer to decide on the correctness of statements. OF COURSE there are ways to define where a statement ends without adding a semicolon to each one, just like there are ways to decide where blocks end in an indent-based programming language; they are embedded in the language syntax.
Heck, C is notorious for producing incorrect code for NOT using meaningful indentation and relying on delimiters instead. If you write:
if (x>0)
function(1);
else
function(2);
if (x>0)
function(1);
else
function(2);
function(3);
But I'm not letting it do that, I'm letting the computer autoformat it, which it can't do if the whitespace is the code.
> Then function(3) will be compiled out of the if sentence, when it's clearly part of the else block.
And yet, I don't have to worry about that error because the editor is able to simply autoformat it so I can see where the error is even when the compiler/interpreter thinks it's legal code!
That's the whole point - using whitespace as part of the code means that the IDE can not, and never will be able to, autoformat the code.
Your example is one of a burden that falls to the programmer in Python, but is taken care off by the computer in other languages.
These errors, which can be automatically found by the computer in other languages, have to be manually found by the programmer in Python. It's a clear disadvantage.
Of course it can do it. Indentation changes are parsed as delimiters, so it can treat them in the same way as if you put those delimiters yourself by hand.
> And yet, I don't have to worry about that error because the editor is able to simply autoformat it so I can see where the error is even when the compiler/interpreter thinks it's legal code!
Nothing prevents an IDE to highlight that error through other means. Ever heard of secondary notation? You don't need explicit delimiters to apply them, when indentation changes work as delimiters themselves. Simply highlight the start and end of blocks, and you'll get the same exact benefits as with programming languages based in brackets.
> These errors, which can be automatically found by the computer in other languages,
So tell me, how would the computer find an error if you have unmatched open/closed brackets? Doesn't that mean that other computer languages have errors that can't exist in Python?
> Your example is one of a burden that falls to the programmer in Python, but is taken care off by the computer in other languages.
How does an error in C code fall to the programmer of Python?
BTW, do you understand Python block delimiters at all? Your complaint seems to come from not understanding how a Python developer sees indentation. Once you enter this mindset, indentation errors are no different than unmatched open/close brackets - which do exist in languages like C too.
> That's the whole point - using whitespace as part of the code means that the IDE can not, and never will be able to, autoformat the code.
No - it means that indentation changes are meaningful, so the state of the code before reformatting should be maintained after reformatting. As long as the reformat tool doesn't change the meaning of the Python code, it will autoformat code perfectly fine, as numerous autoformatters in existence prove.
https://www.kevinpeters.net/auto-formatters-for-python
Which is what I was referring to in my first comment - you need an IDE that understands Python syntax, not just one that blindly pairs open/close delimiters.
It could be pasted at a completely wrong position of course, before some other expression or after some other expression, where it should not be. Aside from that however, the programmer cannot make a mistake by pasting it in a place, that is between 2 expressions, because that is one potentially huge correct position to paste that code. It stretches from the end of one expression to the beginning of the other expression. Anywhere in between the programmer can paste code.
In contrast to that in Python and other whitespace-sensitive language, one has to be very careful about where to paste. Only in the case of pasting at the semantically correct indentation level (basically one tiny position in the code) can the editor/IDE/tool know how to indent things. Of course humans make mistakes and paste maybe 1 space to the left or right or even a whole indentation left or right of the correct position and then the tool cannot help you make your code do the right thing. It could be valid code, accepted by the compiler or interpreter, but still semantically wrong, doing something you did not want it to do.
The tool cannot fix the pasting at wrong position mistakes made by humans in all generality, because it does not know the actual intention and it can be ambiguous what the result should be.
I hope this makes a long discussion a bit clearer.
Just because you paste a bunch of code after `then` in Python doesn't mean all of it goes into `then`.
It's not rocket science, just following the language indentation rules for defining blocks. If the language parser can do it, why not the text editor?
Will it? Are you sure?
> Just copy it to the new position, and change the indentation level to that of the target position, maintaining the same block definition.
"Just" copy. "Just" manually re-indent it.
Remember, we're talking about an IDE automatically figuring out proper indentation for something.
> If the language parser can do it, why not the text editor?
Because constructs that are valid from the compiler's point of view may be ambiguous fro the program's point of view: https://news.ycombinator.com/item?id=34235121
> Will it? Are you sure?
Yes, it's defined as part of Python specification. https://docs.python.org/3/reference/lexical_analysis.html#in...
Indentation increasing or decreasing generates INDENT and DEDENT tokens, which are used as block delimiters.
> Remember, we're talking about an IDE automatically figuring out proper indentation for something.
The IDE doesn't need to figure out whether the program is correct. Only has to treat code blocks as defined by the language syntax. In your linked example:
if x > 0:
function1()
function2()
function3()
if x > 0:
function1()
function2()
function3()
if x > 0: {
function1()
function2()
function3()
}
if x > 0: {
function1()
function2()
}
function3()
With this code:
indent(1)
indent 2
if x<0:
function 1
function 2
function 3
indent(1)
if x<0:
function 1
function 2
function 3
indent 2
if x<0:
function 1
function 2
function 3
indent(1)
if x<0:
function 1
function 2
function 3
indent 2
if x<0:
function 1
function 2
function 3
Exactly. It treats these blocks as such. And it will inevitably format them incorrectly from the programmer's point of view.
> because in both cases there is a precise rule to define where blocks start and end.
And this precise rule inevitably formats code incorrectly from the programmer's point of view in a significant amount of cases.
Only for programmers who are significantly unaware of how the Python language structures its code.
It's not that difficult really. And if you have problems visualizing them, you could use editors like Visual Studio Code, which highlights indentation so that you can see the start and end of blocks with colors, way easier than with start and end brackets.