6 ms·
This is a great discussion with many a differing point of view. To some, significant indentation is better. Others — too used to braces — miss them dearly in
by necovek 2y ago
This is a great discussion with many a differing point of view.
To some, significant indentation is better.
Others — too used to braces — miss them dearly in Python.
Next ones, vie for the non-text source code, something to get us past these discussions altogether (editors working on .pyc files directly?).
For programs to be maintained, they need to be read, understood and improved. One—often undervalued—skill in programming is to write beautiful code, because that is more art than craft. And unfortunately, tools like Black prohibit the true artists from expressing themselves clearly with code formatting too. And to those, white-space or braces matters on a different level, and everything else is attempting to make up excuses for why one is better than other.
And while conceptual operations we do on the code seem simple on the surface, devising an editing tool that would do semantic operations on the AST is fricking hard and likely to be very non-ergonomic. Look at all the attempts to make code refactoring tooling: it's crazily complex and confusing that it's simpler to just go and grep for a string and fix anything you find.
As long as it's faster to use regular editing operations to shuffle code around, indent or unindent it (or wrap it with braces), tweak one thing here or there, simple text editors will mostly rule the world of programming.
- mjevans 2y agogo fmt is really nice, that there is A standard for the language which is just included. No more arguments, just do what the including tooling desires. Python... I'd love if it shipped with a formatter that converted indents to braces, and then had an option for expressing indent as spaces (with number of spaces per indent) OR tabs (same, default 1); then still kept the braces.
- sigzero 2y agoI really hate the "tab width = 8" though.
- moonlion_eth 2y agoThere are kids out there with tab width 16 you should be grateful
- winocm 2y agoAnd there’s also people who use tabstops of 3.
- arp242 2y agoYou can use a tabstop of 4, or 2, or whatever you want. It's not a problem. Don't need to use 8.
- duncan-donuts 2y agoI think people are actually searching for Lisp far more than we are willing to admit.
- kazinator 2y agoPython encodes structure in only one way, using indentation. There is no redundant signal that can be checked for a discrepancy that could indicate a problem. GCC and Clang can diagnose when indentation is "misleading" because it doesn't match what the braces are saying. Python's choice of representation is such that two different Python programs show zero differences under a white-space-suppressed diff. The white-space suppressed diff is a useful tool for comparing programs when some sections of code have changed indentation but are otherwise the same; yet we cannot rely on it if we are using Python. Python's syntax design is objectively poor on several purely technical points. In its favor, there are only handwaving pop psych arguments.
- thoutsnark 2y agoI strongly agree with your main point that pythons syntax design is objectively poor, but content that even the grace you seek to extend to it is wrong >Python encodes structure in only one way, using indentation Except when you write a multiple line string using """ notation. Or when you put things inside parenthesis, which i have seen as the preferred solution for method chaining. Point is, python claims indentation is all that is needed, and then very quickly breaks it's own rule.
- necovek 2y agoOpen parentheses and "multi-line" strings are simply Python's way to allow a single statement to span multiple lines in a nicer way: incomplete expressions continue across the newline (you can also do that with a common Unix way of escaping the newline — backslash right before you start the new line). FWIW, even """ notation does not require a string to be multi-line — it mostly allows using less escaping for things like newlines but also quotes. A preferred way to chain methods is to store values in descriptively named intermediate variables: it would also ease debugging as you'll get a direct pointer to the line that is problematic. Though, TBH, that's probably bad API design (I know it's common with DB query syntax, but that's attempting to turn SQL query construction into objects when they really aren't). Python, like most languages, doesn't really stop you from doing crazy stuff. But also like most languages, it can be done really well.
- 2y ago